В примере свойство Text привязывается к свойству Number вью-модели через конвертер, но по условию к этому числу нужно добавить заголовок окна приложения.
И вы предлагаете часть конвертации выполнять в самом конвертере, а другую часть — code behind. Это не хорошо. Вся логика должна быть в конвертере.
Да, я имею в виду редактирование разметки, не рантайм. Чтобы удалить строку, приходится редактировать Grid.Row элементов из строк ниже. Но тут уже предложили решения:
1. Говорят, Blend умный и умеет сам менять номера строк, когда надо.
2. StackGrid из Catel.
Спасибо, интересный велосипед, конечно, но ничего принципиально нового. Всё так же мы объявляем номер столбца/строки для каждого элемента.
Лично мне было бы интересно вот что
Допустим, есть у нас грид с 10-ю строками. В каждой по много элементов. И вот нам понадобилось удрать строку №2 со всем её содержимым.
Как решить:
1 — удалить элементы из строки №2 и сделать её рамер = 0. Плохо, засоряем код.
2 — удалить элементы из строки №2 и саму строку тоже, а для элементов из нижних строк уменьшить Grid.Row на 1. Очень неудобно, т.к. элементов много.
Хотелось бы иметь возможность указывать номер строки/столбца не абсолютно, а как-нибудь относительно.
У самого пока руки не доходят, может Вам будет интересно :)
Всё правильно. Потеряв мотивацию, любой специалист уйдёт со временем. Не обязательно бывший новичок. Если нет возможности стимулировать деньгами/новыми должностями/проектами/ещё чем-нибудь, то человек уйдёт рано или поздно.
Да, работать не будет, вы правы. Но вы как-то скомкано описали причину. Binding.ConverterParameter — не DependencyProperty, поэтому ему нельзя присвоить Binding, вот и всё.
Также очень актуален вопрос о том, почему все таки без BindingProxy не работает.
Смысл ответа, который вы нашли, близок к истине. Создаваемый объект конвертера не наследует DataContext окна. Да и как ему это делать? Мало того, что он не визуальный элемент, так у него даже свойства DataContext нет. :) Где ему искать FirstName и Age?
Поясните, а зачем этот велосипед? Почему бы просто не использовать MultiBinding / IMultiValueConverter?
«Вопрос привычки» — он вовсе не «лишь», это очень большое дело. И да, рано или поздно ситуация поменяется, ибо ничто не вечно. Только произойдёт это, скорее всего, быстро, революционно, это было в приведенных Вами примерах, с мобильными платформами. И предсказать заранее это невозможно. То, как сейчас продвигается линукс, ничего в ближайшем будущем ему не сулит.
Я же не говорю, что Microsoft должны WoT писать. Платформе нужны success stories. И полноценная WoT была бы отличным вариантом. А то, что WoT Blitz соизволили-таки собрать под винду, как всегда, с огромным отставанием по времени от Ios/Android — не повод для гордости.
Включать в контракт класса, владеющего ресурсами, реализацию IDisposable — это паттерн.
Пруф?
А вот включать в контракт класса контроль его единственности на процесс — это антипаттерн
А где вы у меня это увидели? Впрочем, споры о том, чем является синглтон, паттерном ли, антипаттерном, не утихают по сей день :)
В задаче достаточно информации для решения.
В задаче недостаточно задачи :) Вы мне диаграмму классов словами описали, которая сама уже является решением некой абстрактной задачи. Причём сомнительным решением.
Но раз уж на то пошло, что предлагаете вы?
Не будет. Класс, владеющий ресурсами, которые нельзя освободить автоматически, обязан дать возможность сделать это вручную. В какой именно момент освобождать — ответственность не объекта, а его владельца.
То, как класс следует использовать, определяется при проектировании класса. И если класс реализует IDisposable, то это означает, что для его объектов должен быть обязательно вызван Dispose(). Через using, finally или ещё как-нибудь, но вызван. Это не значит, что Dispose нам дали, а мы решаем, дёргать его или нет.
Например, если я реализую класс SingleInstance, задача которого — держать открытым некий файл на протяжении работы процесса для контроля единственности запущенного экземпляра, я вызову Dispose() у файлового потока (он обязан быть вызван по задумке его разработчиков) в ~SingleInstance. А SingleInstance.IDisposable реализовывать, на всякий случай, я не буду. Потому что так класс задуман, такая у него задача.
Так что вы будете делать в условиях задачи?
Приведите условие конкретной задачи, как я привёл выше. «Сделайте класс, который может освобождать ресурсы в произвольный момент» = «Реализуйте IDisposable», да. Но необходимость освобождать ресурсы в произвольный момент должна быть чем-то вызвана. Она не безусловна, как вы утверждаете. И уж тем более такая необходимость крайне сомнительна, когда речь идёт об очень большом ресурсе, разделяемом между большим количеством потребителей.
Вызов Dispose у LifetimeScope автоматически вызовет Dispose у всех созданных в ней объектов.
«Дорогой объект, который жрет четверть всей доступной вам памяти за счет требующих очистки ( в подходящий момент !) ресурсов». Это условие? )) В таком случае реализация будет зависеть от того, что является «подходящим моментом» или кто его определяет.
Кстати, даже если регистрировать объект как синглтон — он обязан быть Disposable, если имеет ресурсы, не очищаемые сборщиком мусора.
На самом деле IDisposable — это аналог RAII. Отличие в том, что там деструктор вызывается гарантировано и детерминировано, а в c# для этого используется связка using/dispose. Т.е. когда класс проектируется как IDisposable, то предполагается, что его инстанцирование будет производиться в using. Если он является частью агрегата, то корень этого агрегат должен вызывать его Dispose в своём Dispose (в случае RAII деструкторы частей агрегата вызываются при разрушении корня агрегата). В DI-контейнерах такие объекты регистрируются как transient и освобождаются явно, как конкретно — зависит от контейнера.
И вы предлагаете часть конвертации выполнять в самом конвертере, а другую часть — code behind. Это не хорошо. Вся логика должна быть в конвертере.
1. Говорят, Blend умный и умеет сам менять номера строк, когда надо.
2. StackGrid из Catel.
Как решить:
1 — удалить элементы из строки №2 и сделать её рамер = 0. Плохо, засоряем код.
2 — удалить элементы из строки №2 и саму строку тоже, а для элементов из нижних строк уменьшить Grid.Row на 1. Очень неудобно, т.к. элементов много.
Хотелось бы иметь возможность указывать номер строки/столбца не абсолютно, а как-нибудь относительно.
У самого пока руки не доходят, может Вам будет интересно :)
Исходя из названия статьи и первых её фраз можно было подумать, что вы собираетесь утверждать о ненужности server-side rendering как такового :)
Смысл ответа, который вы нашли, близок к истине. Создаваемый объект конвертера не наследует DataContext окна. Да и как ему это делать? Мало того, что он не визуальный элемент, так у него даже свойства DataContext нет. :) Где ему искать FirstName и Age?
Поясните, а зачем этот велосипед? Почему бы просто не использовать MultiBinding / IMultiValueConverter?
Да ну? Пример с эксепшном не приведёте?
Ну а покуда эти проблемы есть, о таком проценте линуксоидам можно лишь мечтать :)
Предполагаю, что код был бы более причёсан, если бы использовался WCF, а не сокеты.
Пруф?
А где вы у меня это увидели? Впрочем, споры о том, чем является синглтон, паттерном ли, антипаттерном, не утихают по сей день :)
В задаче недостаточно задачи :) Вы мне диаграмму классов словами описали, которая сама уже является решением некой абстрактной задачи. Причём сомнительным решением.
Но раз уж на то пошло, что предлагаете вы?
То, как класс следует использовать, определяется при проектировании класса. И если класс реализует IDisposable, то это означает, что для его объектов должен быть обязательно вызван Dispose(). Через using, finally или ещё как-нибудь, но вызван. Это не значит, что Dispose нам дали, а мы решаем, дёргать его или нет.
Например, если я реализую класс SingleInstance, задача которого — держать открытым некий файл на протяжении работы процесса для контроля единственности запущенного экземпляра, я вызову Dispose() у файлового потока (он обязан быть вызван по задумке его разработчиков) в ~SingleInstance. А SingleInstance.IDisposable реализовывать, на всякий случай, я не буду. Потому что так класс задуман, такая у него задача.
Приведите условие конкретной задачи, как я привёл выше. «Сделайте класс, который может освобождать ресурсы в произвольный момент» = «Реализуйте IDisposable», да. Но необходимость освобождать ресурсы в произвольный момент должна быть чем-то вызвана. Она не безусловна, как вы утверждаете. И уж тем более такая необходимость крайне сомнительна, когда речь идёт об очень большом ресурсе, разделяемом между большим количеством потребителей.
Кто вызывает Dispose у LifetimeScope?
Почему Ральфа, а не Михаэля? :)
Служба — это и есть исполняемый файл, зарегистрированный соответствующим образом. Какие ещё «разные виды» ?
Как так? )) А кому же ещё работать в фоне, как не exe?
А чем вам «запущено и просто свернуто» — не работа в фоне? Это более полноценная работа в фоне, нежели то, что предлагает WinRT / UWP.
«Дорогой объект, который жрет четверть всей доступной вам памяти за счет требующих очистки ( в подходящий момент !) ресурсов». Это условие? )) В таком случае реализация будет зависеть от того, что является «подходящим моментом» или кто его определяет.
На самом деле IDisposable — это аналог RAII. Отличие в том, что там деструктор вызывается гарантировано и детерминировано, а в c# для этого используется связка using/dispose. Т.е. когда класс проектируется как IDisposable, то предполагается, что его инстанцирование будет производиться в using. Если он является частью агрегата, то корень этого агрегат должен вызывать его Dispose в своём Dispose (в случае RAII деструкторы частей агрегата вызываются при разрушении корня агрегата). В DI-контейнерах такие объекты регистрируются как transient и освобождаются явно, как конкретно — зависит от контейнера.