Придурок, у CanExecuteChanged не было такой же реализации, текла вся убогая призма. Всё уже давно пофиксили и окно при закрытии прибивает обработчики, неуч. Или тесты на утечку в студию.
Сиди дальше ковыряйся в своем навозе, петушилко. Тебе только кур смешить да со свиньями в отстойнике обниматься - вот твой удел. Как был бестолочью во всём, так ей и помрешь.

Тупорылая blue-кодеманка, ты своим скромным умишком до сих пор не научился читать документацию? А в документации сказано, что прибивается всё, что связано с окном. Обработчики не исключение. Твой поделочный гавнопризм просто окончательно отрафировал твой недомозг, живешь статьями десятилетней давности, когда xaml был еще тем ушлепным механизом. Сейчас всё не так, функционал Close сделает всю грязную работу. Это даже дети знают: IDisposable member of WPF Window class

...Alternatively you could add an event handler the the Window. Closed event and do your disposing there .

...Approaches you can use:
Use Closed event on Window.
Implement IDisposable interface yourself for this Window.

Слабые ссылки в твоей тупой голове, а не в WPF, бестолочь. Иди кур паси лучше, это единственное, на что ты годишься.

А до WF ты еще не дорос и не дорастешь никогда, поэтому даже не начинай. Только нативный SQL можно использовать таким тупицам, как ты. Никаких абстракций, чистый хардкор.

МСУА до EF ты еще не дорос

Элементарный пример показал, что никакой разницы по памяти нет с RelayCommand и без такового. Монопенисуально.

SeVaМуслим, единственное, что ты можешь показать - это фигу в кармане.
Это бред только подтверждает, что ты полный му**к и даже не понимаешь о чем идет речь.
За это домашнее задание тебе два, завтра утром попробуй показать нормальный вариант,
который должен быть, чтобы показать утечки.

Ссылку с готовым примером я тебе уже давал. Твой кишлак даже по готовому коду ничего сделать не может?
Тебе даже баранов пасти опасно доверять.
Долбосев, ты укуренное полуобморочное чмо, которое не может осилить элементарного примера, который черным по-белому демонстрирует тот факт, что ты гавно. Как в прямом так и переносном смыслах.
Ты уже битый день пытаешь родить утечки на пустом месте, пока получается рожать только фекалийные массы прямо из твоего поганого рта. Собственно, в чем и выражается твоя гнилая натура.
Ты еще не дорос до этого кода, голубок. Пастбище баранов таки отдыхает. Попробуй потужиться, может получится родить что-то более или менее приемлемое по теме. А пока ты обычный ублюдок, от которого в форуме поднимается лишь пыль.

SeVaГде ты этот маразм вычитал? Сначала создаем себе грабли, а потом в каждом окне на них наступаем.
Чучело, что нужно сделать сделать, чтобы отписаться?
А документации я этот маразм вычитал, бестолочь. Грабли создаются у тебя в башке, чудовище. Закрывай окно и ни о чем не думай.

Лёня, а xaml таки ничего, мне он всё больше и больше нравится :)

Алексей КСделай лучше что-то вроде
Ок. Но вся проблема (по моим тестам), что вообще весь WPF течет. Код даже без ICommand протекает, проверь сам. Да и вообще, попробовал создать тыщу окон, потом в цикле их закрыл, даже вызвал GC.Collect. До коллекта было очень много мусора, после него немного прибралось. Но на 20% память таки выросла. Повторил еще 4 раза это дело, в итоге память выросла до 200Мб. Я в шоке. Весь XAML течет, мать его...

Алексей КПодожди, глубже копнёшь - он тебя ещё выбесит. :-)
HTML наше всё? )

Алексей КНу не знаю. Утечек в WPF4 не замечал. Попробуй ICommand поправить. Вероятно в нём дело. Если даже не в нём - твоя совесть будет чиста. :-)
Пробовал уже :) Вот тут я пример выкладывал 15143865 , закомментируй button.Command и проверь. Утечек немеряно.

Меня всё больше и больше радует WPF

SeVaА нечего там комментировать. В прошлый раз смотрел бегло(очень опасно глубоко нырять, можно не отмыться потом), эта лошара даже единственную статью не осилила, сделала совершенно в тупую и даже не удосужилась реализовать полностью весь функционал. CanExecute всегда true.
Пионерская поделка без всякого смысла.
А нечем тебе комментировать ибо вместо башки у тебя помойное ведро. Это идеологический концепт и мне на данный момент не нужен CanExecute. Ты со своими обработчиками скоро слюной изойдешь, бездарность.

SeVaМуслима, большой мальчик, а до сих пор не знаешь, что сборка мусора совершенно не означает полную очистку. Где и кем ты работаешь?
Присаживайся, двойка. Весь .NET так работает, в том числе WinForms.

http://msdn.microsoft.com/ru-ru/library/system.gc.collect(v=vs.110).aspx GC.Collect принудительно запускает немедленную сборку мусора для всех поколений.


Ляпнул очередную глупость, впрочем как всегда. Если осталась хоть капля головного вещества, запусти тот же пример генерации объектов на WinForms и прибей форму. Память честно вернется на исходную позицию.

Monochromatiqueo_O

Так ты чморил SL ничего о нем не зная??
o_O

Так SL у нас уже стал XAML'ом?

Алексей КУ меня стойкое убеждение, что валидацию надо делать во View. Как раз для того, чтобы не дублировать свойства модели во вьюмодели.
Таки я не понял, о каком дублировании идет речь. WPF поддерживает только штатную IDataErrorInfo, тем самым описав валидацию во вьюмодели, нигде больше её описывать не потребуется. Бери да и расставляй только ValidatesOnDataErrors=True в представлении. Во-вторых, еще один плюс штатного IDataErrorInfo - переносимость. Это будет работать и в MVC, и в консольном приложении и везде. Я категорически против валидации во вью - напоминает убогие валидаторы уровня представления в WebForms. Мрак. Так зачем же брать плохие практики в XAML? :) Жалко, что нативно не поддерживается DataAnnotations как в MVC, но думаю это дело времени.