DI на этапе создания контрола из XAML

@kotelok · Регистрация: 08.08.2014

Студворк — интернет-сервис помощи студентам

Есть простейший ContentControl, расположенный в какой-то вспомогательной общей библиотеке:

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
    public sealed class ViewModelControl : ContentControl
    {
        public IViewService ViewService { get; set; }
 
        public static readonly DependencyProperty ViewModelProperty = DependencyProperty.Register(
            nameof(ViewModel),
            typeof(object),
            typeof(ViewModelControl),
            new PropertyMetadata(default(object), OnViewModelChanged));
 
        public object ViewModel
        {
            get => GetValue(ViewModelProperty);
            set => SetValue(ViewModelProperty, value);
        }
 
        private static void OnViewModelChanged(DependencyObject o, DependencyPropertyChangedEventArgs e)
        {
            this.Content = ViewService.LoadUserControl((o as ViewModelControl).ViewModel);
        }
    }

И он используется в каком-то XAML:

XML
1
<vm:ViewModelControl ViewModel="{Binding Path=NestedViewModel}" />

И в каком-то приложении на базе этого XAML создаётся 'UserControl', который где-то размещается:

C#
1
window.Content = Application.LoadComponent(viewXamlInfo.Uri);

И в рамках этого 'LoadComponent', помимо прочего, так же создаётся один (или боллее) экземпляр 'ViewModelControl' (т.к. он есть в XAML).

И далее этому экземпляру 'ViewModelControl' в некий момент в рантайме приходит событие 'OnViewModelChanged' и ему нужно через 'ViewService', для текущего типа экземлпяра 'ViewModel':
1. Найти XAML, который сопоставлен данной ViewModel (логика сопоставления известна только уровню приложения, т.е. там, где происходит 'Application.LoadComponent').
2. Cоздать UserControl на базе этого XAML.

Вопрос: как наименее затратно по коду/времени и не нарушая иерархию зависимостей выдать всем экземплярам 'ViewModelControl' (созданным в процессе создания контрола на базе XAML) экземпляр сервиса 'IViewService' (реализованого на уровне приложения, которое всё это использует)?

Пока что единственный вариант, что удалось придумать - после выполнения 'Application.LoadComponent', пройтись при при помощи 'LogicalTreeHelper' по всему дереву элементов, найти все экземпляры 'ViewModelControl' и выдать им реализацию сервиса резолва/создания View через внешнее свойство типа IViewService.

Однако, это не самый быстрый вариант, особенно, для XAML с большим количеством элементов.

@Элд Хасп · 29.10.2020, 20:53

Сообщение от kotelok

Ну так я потому и пришёл к этому, что не хватает.

Вот из всей вашей темы я не вижу в каком сценарии вам может не хватить Шаблонов данных по умолчанию и Селекторов Шаблонов.

Поэтому у меня большие подозрения, что вы просто плохо знаете инструменты WPF.

Сообщение от kotelok

P.S.: оговорюсь, что да, вероятно на данном этапе я не вижу каких-нибудь катастрофических минусов подхода VM-first

А вы и не увидите, пока не сможете в полной мере использовать весь инструментарий WPF.
Вам же не с чем будет сравнивать.

В этом и беда корифеев о которых я писал выше.
Они даже не понимают, что то, что они пишут значительно сложнее, чем если это делать предусмотренными для WPF средствами.

kotelok, если вы убеждены делать как-то по своему - делайте.
Кто вам может запретить.

Я всего лишь пишу, что с очень большой вероятностью вы плохо изучили WPF.
И советую сначала нормально его изучить.
Потом вы хотя бы сможете объективно сравнить оба подхода.

@kotelok · 29.10.2020, 21:28 **[ТС]**

Сообщение от Элд Хасп

Вот из всей вашей темы я не вижу в каком сценарии вам может не хватить Шаблонов данных по умолчанию и Селекторов Шаблонов.

Ещё раз - речь не о том, что не хватает. Речь об усложнении структуры проекта и кода в угоду традиционному MVVM через view-first.

Сообщение от Элд Хасп

Я всего лишь пишу, что с очень большой вероятностью вы плохо изучили WPF.

Скорее всего да, т.к. порог вхождения слишком уж высокий. И формально, это ещё один повод задуматься над более простыми и прозрачными решениями (пусть и не совсем MVVM), которые позволяют получить те же результаты меньшим объёмом кода, более простой архитектурой проекта и с меньшим уровнем знаний. Особенно в свете перспективы вводить в проект других программистов у которых так же будет выбор - использовать простое решение, или же поднимать скилл WPF до очень высокого уровня дабы получить (вероятно) преимущества от работы через традиционный MVVM.

P.S.: и я не убеждён, я просто ориентируюсь по фактической ситуации ... более того, сам себя я каждый раз пытаюсь убедить, что описываемые вами подходы правильные, что надо через них, что все крупные проекты так делают (наверное), и каждый раз в попытках реализовать что-нибудь простое, рефлекторно начинаю рефакторить код в менее перегруженный и в более дружественный к программисту, в результате чего каждый раз получаются различные варианты ViewModel-first.

@Элд Хасп · 29.10.2020, 21:46

Сообщение от kotelok

Скорее всего да, т.к. порог вхождения слишком уж высокий.

Не слишком, но выше.
Мне хватило 3-4 месяцев осилить и C# (о котором слышал, но ничего не знал), и WPF (о котором даже не знал).
Как ни как основной язык WPF - это XAML.
Это совершенной иной (по сравнению с C#) язык, вообще, лежащий "в другой" плоскости.

Сообщение от kotelok

которые позволяют получить те же результаты меньшим объёмом кода, более простой архитектурой проекта

Вот это совершенно не верно.
Они позволяют получить Решение не изучая нового.
Но Решения получаются более громоздкими и архитектурно сложными.

То есть выбирать приходится между "не учить и сделать по старому, пусть и сложно" или "потратить время и силы на изучение нового и сделать потом проще и лучше".

Добавлено через 7 минут

Сообщение от kotelok

рефлекторно начинаю рефакторить код в менее перегруженный и в более дружественный к программисту

Более дружественный к тому, кто плохо знает используемую среду.

Посмотрите на большинство Решений C# в Консоли и Формах.
Сделаны так, как-будто ООП не существует, я уже не говорю о паттернах программирования.
И все авторы такого кода, тоже убеждены, что делаю проще и лучше.

И оценить объективно это может только тот, кто хорошо владеет ООП и умеет реализовывать паттерны.

Так же и в вашем случае.
Овладейте сначала в достаточной мере WPF и MVVM - тогда сможете судить объективно.

Уже писал в начале темы.
Такой абстрактный разговор выливается в бесполезный холивар.
Надо рассматривать конкретные задачи.
С одной стороны научитесь их реализовывать разными подходами.
С другой набравшись опыта, сможете объективно оценивать эти подходы.

@kotelok · 29.10.2020, 22:01 **[ТС]**

Сообщение от Элд Хасп

Как ни как основной язык WPF - это XAML.

Так он и не оспаривается. Он остаётся в полном объёме. Речь лишь о том, что часть CB, которая отвечает за логику UI (иерархия и взаимодействие абстрактных элементов интерфейса), переезжает во VM и даёт единообразное решение для всех сценариев. VM всё так же предоставляет наружу лишь сырые данные и не занимается форматированием или конвертацией статусов в цвета элементов. Т.е. все конвертеры, хэндлеры, контроло-специфичные настройки UI-компонентов, разумеется остаются на уровне XAML и вспомогательного C#-кода (который так же располагается во View-сборке). Просто точка управления состоянием приложения смещается из View во VM, что автоматически решает некоторые из описанных выше проблем viewfirst-подхода.

P.S.: типичную задачу я уже описывал выше, в случае ViewModel-first она решается через единственный маленький кусочек кода внутри VM (остальное за кулисами делает фреймворк), в случае с View-first - возникает потребность придумывать сложные механизмы взаимной реакции View и VM на изменения состояний друг друга просто чтобы закрыть окно по факту успешнего сохранения данных во VM.

@Элд Хасп · 29.10.2020, 22:10

Сообщение от kotelok

Так он и не оспаривается. Он остаётся в полном объёме. Речь лишь о том, что часть CB, которая отвечает за логику UI...

Если вы в полной мере используете WPF, в том числе XAML, но не только его, то у вас и так пустое CB.
И что вы тогда собираетесь из пустого CB перетаскивать в VM ?

Добавлено через 1 минуту

Сообщение от kotelok

P.S.: типичную задачу я уже описывал выше,

Вы описывали не задачу, а способ её реализации.
И вам сразу написали, что это неверно.

Что за задачу вы хотите решить таким инструментом - вы так и не написали.

@kotelok · 29.10.2020, 22:23 **[ТС]**

Сообщение от Элд Хасп

И вам сразу написали, что это неверно.

Это понятно, но пока я не знаю, как решить её и правильно, и с минимумом кода (не размазанного по куче файлов). Через VM-first получилось даже без сторонней помощи, потому и обратил на него внимание.

Сообщение от Элд Хасп

Что за задачу вы хотите решить таким инструментом

Типичная задача редактирования айтема через даблклик в неё и показ блокирующего диалогового окна (при условии, что окно имеет собственную VM).
Типичная задача создания/удаления nested-контрола (и VM для него) в процессе реакции на какое-то событие модели (или VM).

И ещё раз - я решал эти задачи через View/XAML, но далее не справлялся с попытками довести эти решения до того же уровня простоты кода, что даёт подход VM-first.

@Элд Хасп · 29.10.2020, 22:31

Сообщение от kotelok

пока я не знаю, как решить её и правильно, и с минимумом кода (не размазанного по куче файлов).

??? !!!
Это же ООП !!!
Здесь всегда куча типов, файлов, методов и т.п.

Такая задача не то, что WPF - она самой концепции C# противоречит.
На каждую фигню - надо создавать свой тип.
На каждую операцию - свой метод.
Файлов ДОЛЖНО быть много!

Может поэтому вам и WPF сложно освоить.

Дефолтные WPF элементы - это всего лишь костяк WPF.
А для нормальной реализации WPF Решения к ним создаётся множество различных типов: конвертеры, AP-свойства, Behavior, Триггера, разнообразные контейнеры, статические классы с обработчиками, UserContol'ы, Custom Control'ы, различные прокси, шаблоны, стили, словари и т.д. и т.п.
Не создавая всего этого, конечно, трудно будет только на дефолте красиво реализовать WPF Решение.

@kotelok · 30.10.2020, 00:12 **[ТС]**

Элд Хасп
Это всё очевидно, да. И я тоже предпочитаю максимально разделять код на маленькие блоки, если вдруг один класс начинает выполнять хоть немного не свою работу.

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

Добавлено через 15 минут
Если не сложно, приведите вариант XAML-разметки под конкретный пример.

В разметке есть кнопка. При нажатии на эту кнопку нужно:
1. Создать диалоговое окно, создать для него VM, передать ей параметр, связать VM и созданный View.
2. Показать окно модально, дождаться пока пользователь его закроет.
3. По результату закрытия окна сделать что-то с той VM из окна которой нажималась кнопка.

При подходе VM-first в XAML будет:

XML
1
<Button Command="{Binding DoSomeCommand}" />

В коде VM будет:

C#
1
2
3
4
5
6
7
8
9
public ICommand DoSomeCommand { get ....
 
public void DoSomeExecute(object parameter)
{
    if (viewService.ShowAndWait(otherViewModelFactory.Resolve(this.SelectedId))== true)
    {
        this.Other();
    }
}

Т.е. ровно одна привязка и ровно один метод. Остальное спрятано внутри фреймворка. И в данном случае не требуется больше вообще никакого дополнительного кода, никаких элементов разметки, которые можно забыть, в которых можно ошибиться. Если же мне, каждый раз при необходимости реализации такого типового функционала, придётся помнить, что ещё нужно вон там прописать хэндлер на закрытие окна, вон в той VM подписаться на событие и обработать его, то это автоматически сразу же приведёт к мыслям, как бы оптимизировать решение дабы избавиться от всей этой рутины.

Вероятно, именно в силу нехватки опыта и усидчивости, у меня не получилось свести этот код к тому же минимуму при работе от View.

@Элд Хасп · 30.10.2020, 09:59

Сообщение от kotelok

Остальное спрятано внутри фреймворка.

А вот это тоже одно из ключевых условий.

Мы обсуждаем тот или иной подход при реализации на "дефолте" или при использовании какого-то фрамеворка?

Если первое, то все "внутренности фрамеворка" тоже являются частью реализации вашего подхода. И он получится, без вариантов, на много сложнее чем любой "дефолтный" вариант.

Если же второе, то конечно использование средств фрамеворка сокращает код и здесь можно только обсуждать какой фрамеворк лучше подходит для каких типов задач.
И "сокращает" далеко не всегда означает "улучшает".

Сообщение от kotelok

Если не сложно, приведите вариант XAML-разметки под конкретный пример.

А давайте глянем глубже.

Задача ли это?
Откуда взялись эти условия?

Конечно, это не Задача.
Её можно назвать Локальной задачей поиска решения для уже в большей части созданного окружения.
Задача более глобальна.
И эти условия появились исходя из вашего понимания как нужно реализовать саму Задачу.

Как вы построили архитектуру приложения.
Вы это делали исходя из своих знаний и вполне вероятно выбрали неверную архитектуру.
Подогнанную не под оптимальное использование WPF, а под имеющиеся у вас знания.
И в такой неверной архитектуре у вас возникает потребность в реализации определённых действий.
Но может в оптимальной архитектуре в них не возникла бы потребность?
Или потребовались другие?

Сообщение от kotelok

При подходе VM-first в XAML будет:

Разберу сначала ваш вариант решения.

Сообщение от kotelok

XML
1
<Button Command="{Binding DoSomeCommand}" />

Что делает эта команда?
С вашей точки зрения она выполняет первый пункт условий.
Но это не так.
Если мы говорим о НЕЗАВИСИМЫХ слоях MVVM, это вызов команды VM.
Будет ли по ней открыто окно или нет автор View, в принципе, знать не может.
А верно ли это?

А если он считает, что лучше в GUI дизайне для редактирования параметра надо не открывать новое окно, а перейти в текущем на другую страницу, или в текущем Окне создать регион для редактирования?
Что ему делать?
Ему придётся обращаться к автору VM с требованием изменить РЕАЛИЗАЦИЮ команды!

Тем самым в таком подходе, вы делаете VM частью View и создавать их независимо друг от друга просто невозможно.
То есть , фактически вы выкидываете VM из MVVM.
Да, у вас есть некий тип который так НАЗЫВАЕТСЯ, но по функционалу он ни как не ViewModel.
Это либо часть View, либо какая-то смесь с Контролером/Презентером.

Сообщение от kotelok

C#
1
public void DoSomeExecute(object parameter)

У вас в команде не используется параметр, но зато используется некое свойсnво VM SelectedId.
А что это за свойство, и для чего оно в VM?
Только для того чтобы быть переданным в команду?
В таком случае у вас опять искусственно внесена часть функционала View в ViewModel.
И в такой смеси часть реализующая это свойство, привязка к нему это тоже часть реализации вашей локальной задачи.

С точки зрения WPF+MVVM, что должна делать эта команда?
Открыть диалоговое Окно для полученного параметра.
Условно это будет так:

C#
3
4
public void DoSomeExecute(object parameter)
    => ShowAndWait(parameter);

Есть в этом коде что-то связанное с VM?
Нет.
И следовательно эта команда не должна быть в VM.

Сообщение от kotelok

1. Создать диалоговое окно, создать для него VM, передать ей параметр, связать VM и созданный View.

Откуда в диалоговом окне VM?
Как эта VM связана с Моделью?
Условно можно в команду выше добавить реализацию метода ShowAndWait:

C#
1
2
3
bool? ShowAndWait(object parameter)
    => (new DialogView() {DataContext = new DialogVM(parameter)})
          .ShowDialog();

Сообщение от kotelok

3. По результату закрытия окна сделать что-то с той VM из окна которой нажималась кнопка.

Зачем и что?

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

P.S. kotelok, ещё раз пишу, я нисколько не настаиваю на том, что чтобы вы делали как я говорю.

Но даже по постановке локальных задач видно, что MVVM до вас "не дошёл".
Из-за неправильного понимания, из-за нехватки знаний по WPF у вас начинаются ошибки уже на этапе проектирования архитектуры Решения.
Вы её проектируете под своё понимание и знания.

Да, вы так сможете реализовать и это вас ещё больше убеждает в правильности собственного выбора.
Получается зацикленность заблуждений с положительной обратной связью.

И по-моему опыту общения вырваться из такого круговорота заблуждений не удаётся почти никому.
Поэтому вы просто решите для самого себя:
- делаю как могу, многие так делают, а если кому это не нравится - чёрт с ними!
- я осознаю, что мне не хватает знаний в этой области, и хочу потратить время и силы (в ущерб остальному) на их получение. И после их получения буду оценивать как лучше.

@kotelok · 30.10.2020, 10:52 **[ТС]**

Элд Хасп
Спасибо, если время будет, попробую на выходных ещё раз с нуля из типового CB-решения получить MVVM-вариант. Хотя, пока что закрадываются подозрения, что конкретно под мои условия MVVM попросту не нужен, т.к. на проекте (несмотря на общий огромный размер) точно не будет разделения программистов слои и логика V+VM всегда будет реализовыаться одним человеком в рамках конкретной UI-задачи, а значит, пусть даже ценой более жёсткой связанности/зависимости V+VM, вполне можно отказаться от сложностей MVVM ради упрощения кода и работы программистов.

@Элд Хасп · 30.10.2020, 11:20

Сообщение от kotelok

вполне можно отказаться от сложностей MVVM ради упрощения кода и работы программистов.

Можно и нужно!
Другой вопрос как оценивать "сложность" и "упрощение".
Оценка субъективна и очень зависима от знаний и опыта субъекта.

Если вам и вашей компании проще так как вы делаете и ни о каких перспективах дальнейшего роста речь не идёт, то, конечно, оставьте всё как есть.

Добавлено через 3 минуты

Сообщение от kotelok

попробую на выходных ещё раз с нуля из типового CB-решения получить MVVM-вариант

Не пробуйте!
Сразу говорю, ничего толкового не выйдет.
Раз в WPF Решении активно используется CB, то с вероятностью 99,99% у Решения неверная АРХИТЕКТУРА.
И надо не ПЕРЕДЕЛЫВАТЬ приложение, а создавать его С НУЛЯ, начиная с проектирования его архитектуры.

@kotelok · 30.10.2020, 11:30 **[ТС]**

Сообщение от Элд Хасп

Раз в WPF Решении активно используется CB, то с вероятностью 99,99% у Решения неверная АРХИТЕКТУРА.

Не, не используется. Сейчас это очень древний WinForms-проект без каких-либо биндингов и полностью реализованный на CB. И есть шанс, что выделят ресурсы на плавный перевод части функционала в полностью новый проект на WPF.

@Элд Хасп · 30.10.2020, 11:33

Сообщение от kotelok

Сейчас это очень древний WinForms-проект без каких-либо биндингов и полностью реализованный на CB

Тогда тем более не получится его портировать в "красивое" WPF Решение.
Надо начинать с проектирования архитектуры.

@kotelok · 30.10.2020, 11:37 **[ТС]**

Сообщение от Элд Хасп

Надо начинать с проектирования архитектуры.

Ну так да. Полностью новый проект. Новый бэк, новый фронт на WPF. Реализация там нового функционала и, вероятно, постепенное портирование (переписывание) части существующего фунционала в новый проект. Единственное, что останется без изменений -хранилище данных. Но оно на архитектуру бэк+фронт не повлияет.

@Элд Хасп · 30.10.2020, 12:18

Сообщение от kotelok

Единственное, что останется без изменений -хранилище данных. Но оно на архитектуру бэк+фронт не повлияет.

Да.
Не должно влиять.
Для WPF+MVVM удобно использовать EF.
У вас как реализовано?

@kotelok · 30.10.2020, 12:31 **[ТС]**

Сообщение от Элд Хасп

У вас как реализовано?

Фронт тонкий. Т.е. вся логика предметной области, работа с базой и интеграция с прочими сервисами спрятаны за API.

Т.е. слой Model на стороне фронта, по-большей части, будет минимальной прослойкой между VM и API. Вероятно, там так же будет какое-то локальное кэширование.

@Элд Хасп · 30.10.2020, 12:45

Сообщение от kotelok

Т.е. слой Model на стороне фронта, по-большей части, будет минимальной прослойкой между VM и API.

Иногда применяется и совмещённая реализация Model+VM.

@kotelok · 30.10.2020, 19:07 **[ТС]**

Не, не получается придумать решение.

В XAML есть кнопка:

XML
1
<Button />

По кнопке надо:
1. Показать другой View модально относительно текущего (в котором кнопка).

Как это сделать:
1. Не перенося логику инициации показа диалога во VM (пусть даже и косвенно через абстракцию).
2. Не используя CB.

Добавлено через 30 минут
Почему-то даже нагуглить это не получается - большая часть примеров через CB, немного через VM, и всё.

Нашёл какой-то вариант через встраивание C#-кода напрямую в XAML, однако, выглядит это совсем уж жутко, да и по-сути это всё тот же CB.

@Элд Хасп · 30.10.2020, 19:51

kotelok, есть два основных способа решения:

Использование обработчика Click.
Можно его задать в CB самого окна, или в его XAML.
Но так же есть варианты:
- создать статический класс обработчиков - ссылку на пример я давал выше;
- сделать статический обработчик в CB диалогового окна. Вызов станет подобен статическому методу MessageBox.Show(...);
- создать AP-свойство или Behavior.

Второй способ - использование команд:
- изначально MS предполагала использование команд только внутри View. Для этого были созданы всплывающие команды RoutedCommand. При всплытии они ловятся и передаются в обработчики. Обработчики присоединяются подобно как выше указанно для Click. Я содавал специальное AP свойства для биндинга RoutedCommand к обычным командам Освоение Attached Properties: Списочное свойство
- задание команды с реализацией. Создаёте экземпляр команды в ресурсах и ссылаетесь на него. Если подобных команд несколько, то удобнее сделать один тип с несколькими свойствами командами.

Как видите вариантов реализации множество - полтора-два десятка.
Какой конкретно выбрать зависит от деталей задачи.

Для вашей, чтобы показать пример, мне нужны уточнения:
- Какой из вариантов вам больше импонирует?
- Что значит "относительно текущего (в котором кнопка)"? Какие "знания" должны быть у Диалогового Окна о Родительском?
- Есть ли какая-то передача данных между ними?

@kotelok · 30.10.2020, 20:15 **[ТС]**

Элд Хасп

Сценарии у меня стандартыне для десктопа:
1. Список айтемов, даблклик в айтем, модальное диалоговое окно редактирования айтема, которое на вход получает ID кликнутой записи, вытягивает её полные данные с сервера, кнопки ок/отмена, и по факту закрытия вызывающая форма получает информацию о результате выполнения (обновлена запись или нет).
2. Кнопка, по которой отображается НЕ модальное окно и ссылка на него запоминается. При повторном клике в кнопку, если окно всё ещё живо, оно просто активируется/восстанавливается, если же пользователь уже закрыл его, то создаётся и отображается новое.
3. Кнопка, по которой отображается НЕ модальное окно с выдачей ему ID записи. При повторном клике в кнопку, если уже есть живое окно с таким ID записи, то оно просто активируется, если нет, то создаётся новое (т.е. одновременно может быть открыто множество таких немодальных окон).

Но примеры пока не нужно, попробую самостоятельно почитать про озвученные варианты решения.

Новые блоги и статьи Все статьи Все блоги /
Мобильное приложение ColorStep pavlinmavlin 17.09.2026 Реализовал приложение Красный, Зеленый, Синий в Unity3d + c#. Название изменил на ColorStep. Приложение прошло модерацию и теперь доступно для скачивания. Делал его сам, шаг за шагом — и вот,. . .	Запрет дублирования строк в табличной части Maks 13.09.2026 Реализация из решения ниже выполнена на нетиповом справочнике "Нормы ТО" с табличной часть "Виды ТО", разработанного в КА2, со следующими реквизитами: - ВидТО (СправочникСсылка. ВидыТО); - ВидГСМ. . .	Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Jin X 06.09.2026 Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Работая с форумом и нейросетями в браузере часто хочется что-то подкорректировать или добавить какого-то функционала. Ниже прикреплён. . .	Программа опроса у.з. расходомера SLS-720F Argus19 02.09.2026 Программа опроса у. з. расходомера SLS-720F Программа опрашивает один раз в минуту три ультразвуковых расходомера SLS-720F через интерфейс RS-485 по протоколу Modbus RTU. Опрашиваются регистры. . .
Hyper-V: Компьютер должен поддерживать доверенный платформенный модуль 2.0. Maks 31.08.2026 При установке Windows 11 на виртуальную машину Hyper-V 2-го поколения вылезла такая ошибка: Решение: в параметрах виртуальной машины, в разделе "Безопасность" (Security) активировать флаг. . .	Архитектура биовида Стива в Майнкрафте: Зачем бонобо кубический каннибализм anaschu 30.08.2026 Кубический Вагинокапитализм в Minecraft: Математический инвариант ОДУ и рок Стивов-бонобо Главная задача разработанной «Модели Всего» — наглядно продемонстрировать наличие системной «судьбы». . .	Оттачиваю умение писать js программы. russiannick 30.08.2026 Проектом выходного дня стало написание Книги шифров Виженера. Итогом стала версия 200, синий туман. Синий туман назван так, потому что замораживает текст под собой. Нажатие синих кнопок управляют. . .	мат медиц модель 30. презентация проекта anaschu 27.08.2026 хоп хоп хоп хидахоп, а я кладую))

@kotelok 1341 / 920 / 265 Регистрация: 08.08.2014 Сообщений: 2,775
	30.10.2020, 10:52 [ТС]
	Элд Хасп Спасибо, если время будет, попробую на выходных ещё раз с нуля из типового CB-решения получить MVVM-вариант. Хотя, пока что закрадываются подозрения, что конкретно под мои условия MVVM попросту не нужен, т.к. на проекте (несмотря на общий огромный размер) точно не будет разделения программистов слои и логика V+VM всегда будет реализовыаться одним человеком в рамках конкретной UI-задачи, а значит, пусть даже ценой более жёсткой связанности/зависимости V+VM, вполне можно отказаться от сложностей MVVM ради упрощения кода и работы программистов. 0

@Элд Хасп Модератор 16166 / 11286 / 2892 Регистрация: 21.04.2018 Сообщений: 33,175 Записей в блоге: 2
	30.10.2020, 19:51
	Сообщение было отмечено kotelok как решение Решение kotelok, есть два основных способа решения: Использование обработчика Click. Можно его задать в CB самого окна, или в его XAML. Но так же есть варианты: - создать статический класс обработчиков - ссылку на пример я давал выше; - сделать статический обработчик в CB диалогового окна. Вызов станет подобен статическому методу MessageBox.Show(...); - создать AP-свойство или Behavior. Второй способ - использование команд: - изначально MS предполагала использование команд только внутри View. Для этого были созданы всплывающие команды RoutedCommand. При всплытии они ловятся и передаются в обработчики. Обработчики присоединяются подобно как выше указанно для Click. Я содавал специальное AP свойства для биндинга RoutedCommand к обычным командам Освоение Attached Properties: Списочное свойство - задание команды с реализацией. Создаёте экземпляр команды в ресурсах и ссылаетесь на него. Если подобных команд несколько, то удобнее сделать один тип с несколькими свойствами командами. Как видите вариантов реализации множество - полтора-два десятка. Какой конкретно выбрать зависит от деталей задачи. Для вашей, чтобы показать пример, мне нужны уточнения: - Какой из вариантов вам больше импонирует? - Что значит "относительно текущего (в котором кнопка)"? Какие "знания" должны быть у Диалогового Окна о Родительском? - Есть ли какая-то передача данных между ними? 1

@kotelok 1341 / 920 / 265 Регистрация: 08.08.2014 Сообщений: 2,775
	30.10.2020, 20:15 [ТС]
	Элд Хасп Сценарии у меня стандартыне для десктопа: 1. Список айтемов, даблклик в айтем, модальное диалоговое окно редактирования айтема, которое на вход получает ID кликнутой записи, вытягивает её полные данные с сервера, кнопки ок/отмена, и по факту закрытия вызывающая форма получает информацию о результате выполнения (обновлена запись или нет). 2. Кнопка, по которой отображается НЕ модальное окно и ссылка на него запоминается. При повторном клике в кнопку, если окно всё ещё живо, оно просто активируется/восстанавливается, если же пользователь уже закрыл его, то создаётся и отображается новое. 3. Кнопка, по которой отображается НЕ модальное окно с выдачей ему ID записи. При повторном клике в кнопку, если уже есть живое окно с таким ID записи, то оно просто активируется, если нет, то создаётся новое (т.е. одновременно может быть открыто множество таких немодальных окон). Но примеры пока не нужно, попробую самостоятельно почитать про озвученные варианты решения. 0