Можно ли что-то делать при обработке события Unloaded с дочерними контролами?
Как лучше сохранить (вернее в каком событии) размеры колонок в ListView?

как-то событие Unloaded совсем не адекватное ... isLoad==false до его появления... это пост событие???

Здравствуйте, VjcheslavV, Вы писали:

VV>Можно ли что-то делать при обработке события Unloaded с дочерними контролами?
А можно для общего развития (я с таким не сталкивался): а что это за событие и у чего оно?

Здравствуйте, Михаил Романов, Вы писали:
МР>А можно для общего развития (я с таким не сталкивался): а что это за событие и у чего оно?
https://learn.microsoft.com/ru-ru/dotnet/api/system.windows.frameworkelement.unloaded?view=windowsdesktop-7.0

Здравствуйте, VjcheslavV, Вы писали:

VV>Можно ли что-то делать при обработке события Unloaded с дочерними контролами?

По идее, можно. К родительским нельзя, а дочерние ещё должны существовать:
https://learn.microsoft.com/en-us/dotnet/desktop/wpf/events/object-lifetime-events?view=netdesktop-7.0&viewFallbackFrom=netdesktop-5.0

VV>Как лучше сохранить (вернее в каком событии) размеры колонок в ListView?

Не знаю как лучше. У меня обычно подобное в Closed окна валяется.

VV>как-то событие Unloaded совсем не адекватное ... isLoad==false до его появления... это пост событие???

Имя события говорит о том, что оно вызывается постфактум.
Closing — перед закрытием окна с возможностью отмены
Closed — по факту его закрытия

Здравствуйте, VVVa, Вы писали:

VVV>Здравствуйте, Михаил Романов, Вы писали:
МР>>А можно для общего развития (я с таким не сталкивался): а что это за событие и у чего оно?
VVV>https://learn.microsoft.com/ru-ru/dotnet/api/system.windows.frameworkelement.unloaded?view=windowsdesktop-7.0
Спасибо!
А я посыпаю голову пеплом: под конец дня прочел Uploaded и выпал в осадок...

По моему опыту вероятность существования событий типа HeaderResized() ниже вероятности сущестования свойства Header[i].Width, поэтому руководствуясь соображениями единообразия aka uniformity, я бы сохранял user preferences именно в unloaded. Я бы обратил внимание на две вещи:
1. Проверку на изменения — для этого можно хранить стейт, с которым view был загружен и сравнивать его с фактическим и сохранять тольк измененное. <сарказм>Уверен, жесткий профессионал на такое и стратегию с визитором может натянуть легко</сарказм>.
2. Чтобы не добвлять время к закрытию и операция тяжеловатая, я бы запускал отдельным потоком, тем более что это fire&forget. не уверен, когда именно рейзится unloaded, можно просто поставить Thread.Sleep(5000) и посмотреть добавляет ли тола. если нет, то не важно.

Все вышеозвученное может быть полнейшей экономией на спичках, если view имеет полтора контрола.

Здравствуйте, 尿컙拋㕪⬎⤇Ǥ꧃푙刾ꄔ൒, Вы писали:

尿Ǥ푙>2. Чтобы не добвлять время к закрытию и операция тяжеловатая, я бы запускал отдельным потоком, тем более что это fire&forget.

Обращение к контролу из другого потока почти наверняка вывалится исключением и всё равно придётся через какой-нибудь Dispatcher получать данные в UI-потоке

в потдельный поток выноситься операция по сохнарнеию преферса, думал, это понятно из контекста.