|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Всем привет, пишу приложение, стараясь придерживаться паттерна MVVM. Интерфейсно это приложение на весь экран с несколькими типами оконных форм. То есть существует текущая форма, которая в данный момент отображается на экране, и в зависимости от определенных условий она меняется на другую. View построил по следующему принципу: Есть MainWindow следующей структуры: Код: xml 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
В качестве CurrentControl буду подставлять различные UserControl, которые представляют собой окна приложения. Для этого MainWindow создаю свою MainViewModel, которая будет управлять всеми окнами в приложении. Сначала создаю базовый класс ViewModelBase, от которого будут наследоваться все ViewModel приложения, чтобы реализовать интерфейс INotifyPropertyChanged. VB.NET Код: vbnet 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
C# Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23.
Код MainViewModel VB.NET Код: vbnet 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.
C# Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25.
,где InputTabControl - UserControl.xaml со своей ViewModel- то есть стартовая форма приложения. При запуске приложения сначала создается MainViewModel, потом ViewModel для InputTabControl. Необходимо, чтобы из ViewModel для InputTabControl при определенных действиях можно было обратиться к MainViewModel и передать ей команду поменять CurrentControl для отображения другого UserControl. Вопрос- правильный ли подход я использую по навигации между окнами текущей задачи и как осуществить взаимодействие между различными ViewModel? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.12.2016, 16:07 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
окно это и так ContentControl, какой смысл вкладывать ContentControl в ContentControl? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.12.2016, 23:09 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Roman Mejtes, xaml главного окна- Код: xml 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
Смысл в следующем: 1) Чтобы поменять текущее окно, я в свойству CurrentControl для MainViewModel присвою другой UserControl, который содержит в себе код xaml разметку окна. Не уверен, что такой подход по навигации между окнами правильный. 2) Для дальнейшей возможности реализации меню в приложении. То есть в MainWindow будет область с элементами, которая все время видна, и будет область с ContentControl. При действиях с элементами в этой области меню содержимое ContentControl будет меняться. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2016, 08:36 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
vb_sub, вы хотите в модели представления хранить представление и подставлять его структуру главного окна? Что-то как-то замороченно и сомнительно. Попробуйте сделать так. В модели представления главного окна хранятся модель представления меню этого окна и модель представления для ContentControl. Смена содержимого CurrentControl происходит через отдачу команды из представления меню в модель представления меню, которая изменяет модель представления для CurrentControl (назовём это "событие А"). Для каждой модели представления, которая будет в CurrentControl, сделайте своё представление в виде DataTemplate. Тогда при событии А нужное представление подставится в ContentControl автоматически. Возможно, модель представления меню главного окна стоит ввести в модель представления окна, чтобы можно было изменять содержимое ContentControl сразу в команде окна, а не городить какую-нибудь сигнальную систему и маршрутизацию между моделями пердставлений (меню и главного окна). ... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2016, 19:42 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Если непонятно, что почитайте, что такое MVVM - в WPF только с этим нормально и можно работать, ибо под это WPF заточен. В вашем случае можно даже без модели обойтись (я не знаю, что у вас за приложение), но то, что я описал выше, затрагивает как минимум связь модели представления и представления. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2016, 19:44 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
ARKssЧто-то как-то замороченно и сомнительно.Веский аргумент, ничего не скажешь... ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 05:32 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Алексей КARKssЧто-то как-то замороченно и сомнительно.Веский аргумент, ничего не скажешь... Как я понял, у него VM подставляет куски V. Это значит, что VM знает о V, тогда как по фен-шую этого быть не должно. Уже одно это говорит об "инновационном" подходе. Если бы это было от корифея, тогда ещё можно было подумать, что там да как - может, действительно что-то инновационное придумал. Но поскольку это от новичка в WPF, то создаётся впечатление о банальном незнании основ и построении сомнительных костылей. Ну а тебе как? Всё показалось понятным в пояснении vb_sub, и ты одобряешь его подход? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 06:46 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
ARKssНу а тебе как? Всё показалось понятным в пояснении vb_sub, и ты одобряешь его подход?Я о том, что нужно оперировать фактами, а не абстрактными суждениями, основанными на современной моде. Каждый подход имеет свои преимущества и недостатки. Если единственным критерием качества является соответствие решения шаблону MVVM, то это просто глупо. Например, подход, приведённый ТС, имеет право на жизнь. Но его недостатком является то, что элемент, содержащийся в свойстве MainViewModel.CurrentControl, нельзя одновременно отобразить несколько раз. Этого недостатка лишены решения, основанные на DataTemplate. Преимуществом же такого подхода является его простота, решения через DataTemplate мне кажутся более многословными. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 08:33 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Алексей КARKssНу а тебе как? Всё показалось понятным в пояснении vb_sub, и ты одобряешь его подход?Я о том, что нужно оперировать фактами, а не абстрактными суждениями, основанными на современной моде. Каждый подход имеет свои преимущества и недостатки. Если единственным критерием качества является соответствие решения шаблону MVVM, то это просто глупо. Просто WPF заточен под MVVM. По крайней мере, под его VM-V часть. У WPF для этого есть инфраструктура. А что-то самодельное всегда будет страдать отсутствием такой инфраструктуры и необходимостью всё написать самому, с соответствующими велосипедизмом, костылями и багами. И чем тебе не нравится MVVM? Его VM-V часть в WPF сделана просто отлично, а с помощью пары полезных подключаемых библиотек получается дополнительный функционал поведений и расширенные команды - вообще конфетка. Или тебе то, что вводится сущность VM кажется слишком громоздким? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 10:22 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Алексей КНапример, подход, приведённый ТС, имеет право на жизнь. Но его недостатком является то, что элемент, содержащийся в свойстве MainViewModel.CurrentControl, нельзя одновременно отобразить несколько раз. Этого недостатка лишены решения, основанные на DataTemplate. Преимуществом же такого подхода является его простота, решения через DataTemplate мне кажутся более многословными. Это преимущество из разряда "кое-как работает на коленке". В других условиях - "шеф, всё пропало!". Один большой недостаток такого подхода - ТС приучится костыли подобные везде пихать, и будет попадать в кучу проблем, чуть шаг в сторону сделает. Ну и в нормальной разработке такой подход просто пошлёт куда подальше. Итого, где применим такой подход? В домашней наколеночной утилите "надо за 5 минут быстро что-то сварганить"? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 10:25 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
ARKssЭто преимущество из разряда "кое-как работает на коленке". В других условиях - "шеф, всё пропало!".Алексей КЯ о том, что нужно оперировать фактами, а не абстрактными суждениями, основанными на современной моде. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 11:03 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Проблема в том, что 95% учебного материала по WPF+ MVVM показано для приложений одного окна. Здесь все понятно и красиво. Но если у меня в приложении может быть 30 различных форм (view), причем они могут вызываться не только из меню, но и из друг друга, то гугление по "wpf mvvm multiple views in one window" приводит к миллиону различных вариантов- от включения в кода в code-behind до использования pages. Причем все это показано максимум на 3-5 различных формах внутри окна. То есть нет устоявшейся best-practice по данному вопросу. Если бы в Winforms я бы сделал эту операцию через 5 строчек Код: vbnet 1. 2. 3. 4. 5. 6.
, то в WPF это далеко не так очевидно. Я совершенно не спорю что мой код велосипедный, однако это единственное на мой взгляд что может заработать. Поэтому и создал пост, чтобы люди посоветовали как они справлялись с данной задачей или имеют какие-либо размышления. Насчет подхода с DataTemplate- если есть 30 различных view, то их нужно все включить изначально? Код: xml 1. 2. 3.
.......... Код: vbnet 1. 2. 3.
? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 11:14 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
vb_subЯ совершенно не спорю что мой код велосипедный, однако это единственное на мой взгляд что может заработать.Не нужно недооценивать "традиционные" подходы, применяемые, например, в WinForms. В WPF они работают не хуже. vb_subесли есть 30 различных view, то их нужно все включить изначально?Если делать по MVVM-ному, то во ViewModel должен жить какой-то идентификатор текущей View. Во View "главной" формы можно вставить DataTrigger-ы или DataTemplateSelector. Если применять MVVM-ный подход, то я бы выбрал первый способ, с триггерами. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 11:35 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Архитектурно приложение выглядит как в примере ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 12:07 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Алексей К, кстати, не так давно столкнулся с такой проблем :) примерно как вы описали. Когда используешь связку ViewModel + DataTemplate (которую я люблю), при "переоткрытии" окна с этой связкой или при переходе на другую страницу приложения и возрате на старую состояния определенный только на уровне View будут сброшены, так как визуальное дерево будет по шаблону отстроено заново. То, есть могут слететь выделения в ListBox'а, если они не синхронизированны с представлением коллекции и так далее. Так, что гонят на автора зря, не даром ContentPresenter представляет возможность отображения содержимого на основе шаблона или на основе содержиомого из готовых элементов. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 14:42 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
vb_sub, есть 100500 примеров многооконных приложений в WPF, где можно вызвать открытие окна из любого слоя. Лично я использую самописное, у меня это примерно так работает: есть Standalone менеджер окон, в котором я вызываю метод OpenDialog или OpenWindow, а в качестве параметра передаю объект модели представления (viewmodel), WM ищет на основе типа модели стиль для окна, создает окно, применяет к нему этот стиль. То есть, для открытия окна мне нужно знать только модель представления. Так же после создания окна к нему сразу добавляются обработчики команд, на закрытие, подтверждения и прочее, чтоб связать это с моделью. В стиле окна я определяю шаблон окна, если нужно, параметры и прочее. Но есть и другие способы, не менее удобные. иногда, когда работаешь с WPF возникает ощущение, что некоторые вещи просто забыли сделать и забили на это основательно. На те же триггеры , которые нельзя определить в самом элементе управления, а можно только в стиле или в шаблоне. Где то читал, что вроде это недоработка и вот вот, это добят, а воз и ныне там :) ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 14:52 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Roman Mejtes, Roman Mejtes WM ищет на основе типа модели стиль для окна, создает окно, применяет к нему этот стиль то есть это практически тоже самое что уже стилизованный готовый UserControl, только более абстрактно? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 15:11 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
vb_subПроблема в том, что 95% учебного материала по WPF+ MVVM показано для приложений одного окна. Здесь все понятно и красиво. Но если у меня в приложении может быть 30 различных форм (view), причем они могут вызываться не только из меню, но и из друг друга, то гугление по "wpf mvvm multiple views in one window" приводит к миллиону различных вариантов- от включения в кода в code-behind до использования pages. Причем все это показано максимум на 3-5 различных формах внутри окна. То есть нет устоявшейся best-practice по данному вопросу. Если бы в Winforms я бы сделал эту операцию через 5 строчек Код: vbnet 1. 2. 3. 4. 5. 6.
, то в WPF это далеко не так очевидно. Я совершенно не спорю что мой код велосипедный, однако это единственное на мой взгляд что может заработать. Поэтому и создал пост, чтобы люди посоветовали как они справлялись с данной задачей или имеют какие-либо размышления. Насчет подхода с DataTemplate- если есть 30 различных view, то их нужно все включить изначально? Код: xml 1. 2. 3.
.......... Код: vbnet 1. 2. 3.
? Гуглить всё же лучше примерно так "C# wpf mvvm with multiple window application". Там тебе примерно скажут, что не всегда нужно полностью следовать паттерну MVVM. Иногда можно и из code-behind вызывать дочернее окно. Другое дело, что тогда тебе будет не так легко натянуть понятие модели представления на такой подход - получится, что у тебя окна в code-behind будут оперировать моделями представлений, что выворачивает MVVM наизнанку - ведь code-behind относится к представлению. Я делал нечно подобное, но выглядело это как костыли, которые за собой тянули другие костыли и т. д. А почему вы привязываетесь к окнам? По сути, те же страницы и есть окна, если я правильно понимаю (сам я страницы не юзал ещё), только их не надо закрывать. Суть-то та же - несколько последовательных блоков интерфейса сменяют друг друга, и в предыдущий блок нельзя попасть, пока не закроешь текущий. Ну и из текущего можно открыть следующий. Окна - это всего лишь один из способов реализации такой логики интерфейса. Страницы - другой способ. Дерево - третий способ. Можно придумать свой способ - весь возможный граф открывающихся окон закладывается в граф наследований моделей представлений, а потом это всё мапится на представления через те же DataTemplate. Вам надо только понять суть, которую я выделил жирным. И то, что во всех стандартных гайдах - да, вы правы - есть только способ однооконного приложения со сменой представлений через DataTemplate. Что-то другое придётся искать или придумывать самому. Вот способ реализации настроек в виде дерева (программа Download Master). Посмотрите, может, вам такое подойдёт. В последовательности диалоговых окон каждое окно соответствует ветке дерева. Суть та же, только дерево компактнее и нагляднее. Подробные настройки справа - это конкретные настройки в текущей подкатегории. Т. е. весь ваш граф вызовов диалоговых окон можно отобразить на такое дерево, и, на мой взгляд, это будет лучше, чем 30 различных диалоговых форм, которые, пооткрывав, будут загромождать весь экран, а потом их ещё и закрывать надо. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 15:31 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Алексей Кvb_subЯ совершенно не спорю что мой код велосипедный, однако это единственное на мой взгляд что может заработать.Не нужно недооценивать "традиционные" подходы, применяемые, например, в WinForms. В WPF они работают не хуже. vb_subесли есть 30 различных view, то их нужно все включить изначально?Если делать по MVVM-ному, то во ViewModel должен жить какой-то идентификатор текущей View. Во View "главной" формы можно вставить DataTrigger-ы или DataTemplateSelector. Если применять MVVM-ный подход, то я бы выбрал первый способ, с триггерами. Как насчёт подхода, что я предложил: составить граф вызовов диалоговых окон, отобразить его на граф вью моделей (например, через включение), для каждой вью модели создать свою вью, отобразить полученный граф вью моделей на дерево и область с контентом справа для текущего выбранного вью? Возможно, для удобства нужно будет создать базовый класс для вью моделей - чтобы на ветки дерева мапились с одинаковыми настройками во вьюхах через DataTemplate. Но это уже детали. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 15:35 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
vb_subАрхитектурно приложение выглядит как в примере ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 15:40 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Roman Mejtesиногда, когда работаешь с WPF возникает ощущение, что некоторые вещи просто забыли сделать и забили на это основательно. На те же триггеры , которые нельзя определить в самом элементе управления, а можно только в стиле или в шаблоне. Где то читал, что вроде это недоработка и вот вот, это добят, а воз и ныне там :) И будет там. WPF всё - устарел и не нужен больше МС. В фаворе теперь UWP. Ты в UWP смотрел - как там дела с "некоторыми вещами"? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 16:20 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
ARKss, форма более успешной реализации меню приложения, как у Вас на картинке c DownLoad Master- это десятая проблема - можно с помощью графа, что будет компактнее и лаконичнее, можно с помощью кнопок- не столь важно. Причем как правило в приложениях Вы можете перейти из одной формы в другую не только через пункты меню, но и через команду из текущей формы. Как например применительно к Вашей картинке, если нажмем "Ок", то перейдем в какую-либо другую форму, причем иногда нужно передавать в новую форму определенные параметры. Вот с этой организацией действий как раз и не все ясно. Страницы не использовал, потому что никогда с ними не работал- если будет вкрай безысходно, то конечно попробую и их, но там тоже своя кухня. ARKssМожно придумать свой способ - весь возможный граф открывающихся окон закладывается в граф наследований моделей представлений, а потом это всё мапится на представления через те же DataTemplate. Способ самый прямолинейный и максимально рабочий, но например если у меня много форм, для них для всех создались модели-представления и представления, а я воспользовался только одной формой из всех. Во-первых скорее всего загрузка всего графа будет делом не быстрым, и на малом количестве форм это будет незаметно, то при добавлении новых это будет все больше ощушаться на производительности. Во-вторых держать в памяти весь граф окон думаю расточительно по памяти. ARKssТ. е. весь ваш граф вызовов диалоговых окон можно отобразить на такое дерево, и, на мой взгляд, это будет лучше, чем 30 различных диалоговых форм, которые, пооткрывав, будут загромождать весь экран, а потом их ещё и закрывать надо Если Вы имели ввиду MDI- интерфейс, то я не про него имел ввиду. Я подразумевал то, что меняющееся содержимое окна может иметь 30 различных вариантов. А приложение может показывать в текущий момент только 1 форму, при переходе на новую старая скрывается/закрывается ( как в ютубовской демке). В итоге все равно приходится отходить от принципов MVVM и во ViewModel создавать экземпляры View и отображать их в contentcointrol главного окна. Если попытаться реализовать все в слое View, то надо будет включать все варианты окон во View главного окна - если таких различных окон много, то xaml раздуется до террабайта. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 16:34 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
vb_sub, попробуйте как я вам сказал у меня в App.xaml хранятся ссылки на все ресурсные файлы со стилями всех окон. ключем для них будет тип модели вот так: Код: xml 1. 2. 3. 4.
есть класс WindowManager который в методе OpenWindow находит в ресурсах приложения модель MainModel, которая наследована от интерфейса IWindowModel (который определен в пространстве имён WindowManager) и который позволяет управлять окном из модели представления (обрабатывать события закрытия окна и блокировать их, сворачивания, разварачивания и т.д.) создает объект Window, задает ему найденный стиль, если стиль не найден, окно не открывается, а выдается соотвествующий Exception. затем WindowManager обёртывает окно в отдельный Wrapper который поддерживает иерархию окон, для каскадного закрытия и т.д. Какие плюсы: мы можем открывтаь и закрыывать окна прямо в ViewModel, при этом ViewModel ни чего не знает ни об окнах, ни о стилях и т.д. в ресурсах мы можем быстро найти какое окно (стиль окна) предназначен для какой модели представления, так как мы связываем их по типу. Мы можем легко из любой точки программы закрыть окно для нужно нам модели просто передав в процедуру закрытия только ссылку на модель. с помощью WM мы контролируем весь геморой с окнами Какие минусы: - не все свойства можно определить для окна через стиль, но всегда можно это решить опять же через WM - для 1 модели представления мы можем задать только 1 стиль, так как нельзя создать 2 стиля с 1 типом они либо будут перекрывать друг друга либо конфликтовать, но это опять же можно решить через WM (перегрузить метод открытия с указанием ключа стиля) - для того, чтоб открыть окно которое будет диалоговым, блокировать parent\owner нужно явно указать либо ссылку на экземляр VM, что может быть не всегда удобно. Но в WM есть свойства MainWindowModel и CurrentWindowModel можно открывая окна привязаться к ним. точно так же я обычно делаю и с Page'ами, каждая модель Page'а наследуется от какого то базового класса или интерфейса аля IMyPage, затем для каждой странички я создаю свой <DataTemplate x:Key="{x:Type MyPage1}"/> В качестве контейнера работает ContentPresenter или ContentControl, в котором определен DataTemplateSelector, который в свою очередь ищет у себя в коллекции шаблоны, либо в ресурсах приложения и т.д. Находит и задает соотвествующий шаблон. На коленке такое написать не получится, но думаю вы часа за 3-4 осилите :) ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 17:46 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
vb_subПричем как правило в приложениях Вы можете перейти из одной формы в другую не только через пункты меню, но и через команду из текущей формы. Как например применительно к Вашей картинке, если нажмем "Ок", то перейдем в какую-либо другую форму, причем иногда нужно передавать в новую форму определенные параметры. Я не понял этого. У вас сразу много форм открыто и вы между ними параметры передаёте, или как? Зачем вообще между формами чего-то передавать? У вас должен быть слой (я назвал это моделью представления), где вы храните все параметры. И формы или представления - это только для отображения этих параметров. Если вы сохранили какие-то параметры в какой-то форме, значит, вы сохранили их на этом специальном слое. Если хотите, можете организовать этот слой так, чтобы другие формы знали о сохранённых параметрах - значит, отдельные элементы этого слоя должны знать о других элементах, где эти параметры хранятся. Как это организовать - наследованием, включением, глобальными сервисами с подписками - это другое дело. Главное, что вы сначала моделируете свой интерфейс в специальном слое, прорабатываете его логику на языке программирования, а только потом на формы его накидываете. После проработки логики интерфейса в классах, вы можете на эти классы нацепить любой вид этого интерфейса - любые представления, любую организацию форм, в наших терминах. Я ещё раз говорю - кто вам сказал, что у вас именно ФОРМЫ? Может, у вас какой-то шаблон, которым вы мыслите, и кроме кучи вызываемых друг из друга форм вам трудно представить что-то другое? Попробуйте продумать сначала свой интерфейс логически, без связи с кучей форм. И тогда, возможно, вы придумаете, что есть организация UI получше (если она действительно есть). Ну и, наконец, если вам как-то удавалось сделать кучу форм на Windows Forms, то абсолютно точно такое же поведение нет проблем получить и на WPF. WPF позволяет один в один писать так же, как на Win Forms. Т. е. если вы не хотите заморачиваться с MVVM, можете просто использовать WPF как WinForms. Тогда от WPF можно взять только компоновочную схему, стили, анимации и прочую подобную гибкость в оформлении, которой нет в WinForms, при этом вам совершенно не обязательно использовать привязки, шаблоны данных, поведения, команды и прочее. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 17:52 |
|
|
start [/forum/topic.php?fid=21&fpage=9&tid=1440579]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
71ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
70ms |
get tp. blocked users: |
1ms |
others: | 16ms |
total: | 207ms |
0 / 0 |