Где лучше в MVVM реализовать дополнительную логику?

@JeyCi · Регистрация: 29.06.2019

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

Комментарий модератора

Тема создана разделением темы Привязка DP-свойства UserControl к вложенному элементу

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

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

так оно (заданный Result) ведь всегда может быть перезадано? или я ошибаюсь... переназначить свойство - это же не удалить/создать объект заново...

мне почему-то кажется, что это не проблема, а как раз и задумано было, чтобы можно было переназначать свойства в зависимости от нужного (например, цвет текста при value>1000, условно говоря) - вот и вынесли это DP в отдельный класс... а за пример реализации и использования в XAML - спасибо!..

? только в каких случаях это DP подключают обычно?.. как по мне, так Styles и Templates и даже Converters - нормальные внутренние (для объекта) свойства, дальше которых уже и придумать нечего (с практической точки зрения) чтобы захотеть подключать из-вне класса ещё и DP за гранью всего, что можно задать и в объекте...

@Andrey-MSK · 29.09.2025, 09:17

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

Ну, как бы смысл CommunityToolkit в том чтобы не создавать явно команд и свойств.

Ну я как-то по старинке всё объявляю

Добавлено через 5 минут
JeyCi, Вот ещё момент. Если команда зависит от состояния коллекции, например от свойства Count, то CanExecute проверяется вот так

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
26
27
28
// Коллекция для привязки в UI
public ObservableCollection<LaborHBWork> LaborHBWorks { get; }
    = new ObservableCollection<LaborHBWork>();
 
public LaborHBWindowVM(IWindowService windowService,
                       IBackgroundTaskQueue taskQueue,
                       IMainDA mainDA,
                       IViewModelFactory viewModelFactory)
{
    _windowService = windowService;
    _taskQueue = taskQueue;
    _mainDA = mainDA;
    _viewModelFactory = viewModelFactory;
    // Подписываемся на события
    LaborHBWorks.CollectionChanged += OnLaborHBWorks_CollectionChanged;
    LaborHBTypes.CollectionChanged += OnLaborHBTypes_CollectionChanged;
}
// Обработка события коллекции
private void OnLaborHBTypes_CollectionChanged(object sender, System.Collections.Specialized.NotifyCollectionChangedEventArgs e)
{
    TransferLaborDataCommand.NotifyCanExecuteChanged();
}
// Обработка события коллекции
private void OnLaborHBWorks_CollectionChanged(object sender, System.Collections.Specialized.NotifyCollectionChangedEventArgs e)
{
    DeleteTypeCommand.NotifyCanExecuteChanged();
    UploadWorksCommand.NotifyCanExecuteChanged();
}

@Элд Хасп · 29.09.2025, 09:24

Сообщение от Andrey-MSK

Если команда зависит от состояния коллекции, например от свойства Count, то CanExecute проверяется вот так

CommunityToolkit это фреймворк "для простых случаев".
Когда требуется белее глубокий контроль, то советовал бы использовать Reactive.

@Andrey-MSK · 29.09.2025, 09:26

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

CommunityToolkit это фреймворк "для простых случаев".
Когда требуется белее глубокий контроль, то советовал бы использовать Reactive.

Да хватает его... Тем более пару строк кода дописать, если вдруг что-то оригинальное нужно, не сложно

@JeyCi · 29.09.2025, 19:35 **[ТС]**

а что насчёт MVVMLight? кто-нибудь юзал?

P.S.
в 2х (3х) словах - по теме:

1) валидация в VM : DependencyObject - PropertyChangedCallback и CoerceValueCallback ...
обработка DependencyProperty.UnsetValue ...

2) чтобы связать события (которые не определены для элементов wpf) с командами - Microsoft.Xaml.Behaviors.Wpf

P.P.S.

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

Обычно try-catch находится в команде ViewModel и оборачивает вызов метода модели. Сообщение в View об исключении может быть реализовано по разному. Первое что пришло в голову:
- Диалоговый сервис;
- Поднятие события;
- VM обертка над connection и в нём свойство для приёма исключения.

Handling exceptions in WPF - или как смотрите на этот обработчик исключений?

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
protected override void OnStartup(StartupEventArgs e)
{
  Application.Current.DispatcherUnhandledException +=
    new DispatcherUnhandledExceptionEventHandler(DispatcherUnhandledExceptionHandler);
 
  base.OnStartup(e);
}
 
void DispatcherUnhandledExceptionHandler(object sender, DispatcherUnhandledExceptionEventArgs args)
{
  args.Handled = true;
  // implement recovery
  // execution will now continue...
}

-- уже вижу, что хорошо смотрите

P.P.P.S.
и пример App:

инициализировать LoginVM, MainVM, подписаться на события OnAutorized, в событие сделать логику открытия/закрытия и задать свойства окон

@Wolfdp · 29.09.2025, 19:38

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

CommunityToolkit это фреймворк "для простых случаев".

Строго говоря стоит стремится к тому чтобы ViewModel состояла только из таких простых случаев, где нужно просто показать что-то на UI или пнуть один-единственные метод Model.

Если проводить аналогию с asp.net MVC, то там толстые контролы считали чуть-ли не антипатерном.

@JeyCi · 29.09.2025, 19:43 **[ТС]**

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

А раз нет действий в GUI, то не подымается CommandManager.RequerySuggestedт и кнопки "сами по себе" не обновятся. Нужно поднятие CanExecuteChanged в командах для обновления кнопок.

вот интересный совет

Or just call System.Windows.Input.CommandManager.Inva lidateRequerySuggested() so that your CanExecute handlers are re-evaluated.

====================
3) про ICommand - а эта реализация из Prism по-лучше? (чем та слабенькая)

Кликните здесь для просмотра всего текста

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
26
27
28
29
30
31
32
33
34
35
36
public class DelegateCommand<T> : System.Windows.Input.ICommand
{
    private readonly Predicate<T> _canExecute;
    private readonly Action<T> _execute;
 
    public DelegateCommand(Action<T> execute)
        : this(execute, null)
    {
    }
 
    public DelegateCommand(Action<T> execute, Predicate<T> canExecute)
    {
        _execute = execute;
        _canExecute = canExecute;
    }
 
    public bool CanExecute(object parameter)
    {
        if (_canExecute == null)
            return true;
 
        return _canExecute((parameter == null) ? default(T) : (T)Convert.ChangeType(parameter, typeof(T)));
    }
 
    public void Execute(object parameter)
    {
        _execute((parameter == null) ? default(T) : (T)Convert.ChangeType(parameter, typeof(T)));
    }
 
    public event EventHandler CanExecuteChanged;
    public void RaiseCanExecuteChanged()
    {
        if (CanExecuteChanged != null)
            CanExecuteChanged(this, EventArgs.Empty);
    }
}

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

Вот моя реализация асинхронной команды, которая показывает исключение, если оно было при выполнении Execute: An example of my implementation of base classes (.Net 8): BaseInpc, RelayCommand, RelayCommandAsync, RelayCommand<T>, RelayCommandAsync<T>.

Благодарю - долго буду изучать... и спасибо, что схемы закинули в эту ветку

@Элд Хасп · 29.09.2025, 20:04

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

Строго говоря стоит стремится к тому чтобы ViewModel состояла только из таких простых случаев, где нужно просто показать что-то на UI или пнуть один-единственные метод Model.

Простейшая задача встречающаяся "на каждом углу".
Есть некая коллекция отражающая многопользовательскую БД.
Коллекция обновляется по событиям модели поднимающимся при изменении БД, в том числе и другими пользователями.
В GUI есть кнопка для добавления сущности. Но если равная сущность уже есть в БД, то кнопка должна быть Disabled.

Где надо реализовать CanExecute команды кнопки? И когда подымать CanExecuteChanged этой команды?

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

а эта реализация из Prism по-лучше? (чем та слабенькая)

Да. В ней есть RaiseCanExecuteChanged.

Но она не обеспечивает потокобезопасность для WPF.
RaiseCanExecuteChanged подымает CanExecuteChanged.
Это событие в WPF обязательно должно подыматься в UI потоке.
Поэтому и метод RaiseCanExecuteChanged должен вызываться только в UI потоке.
А для этого придётся или в VM передавать контекст синхронизации UI потока, либо в View добавлять буфер для маршалинга CanExecuteChanged в UI поток.

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

Благодарю - долго буду изучать...

Это не сколько для применения, а действительно для изучения, чтобы было понимание "что же там находится за кулисами?". Чтобы не относились к этим командам как неким чёрным волшебным ящикам.

@JeyCi · 29.09.2025, 20:14 **[ТС]**

p.s.
ну и thread-safe Observable Collection <ListBox Grid.Row="1" ItemsSource="{Binding Items.AsObservable}" />

@Wolfdp · 29.09.2025, 21:06

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

Где надо реализовать CanExecute команды кнопки?

Сама логика мониторинг в model или BL. ViewModel через какой-то контракт получать это уведомление (event или callback).

Я скорее про то что такой "минимализм" инструмента возможно даже хорошо. Очень часто со временем скатываешься к тому что BL просачивается во все щели: городишь километровый SP ради оптимизации, в эндпоинтах сервиса вместо лаконичного вызова ServiceName.Method тоже разворачивается простыня... А так сам инструмент будет мотивировать не раздувать ViewModel.

@Элд Хасп · 30.09.2025, 00:06

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

Сама логика мониторинг в model или BL.

Мониторинга чего?
Сама же коллекция сущностей в VM.
БД удалённая многопользовательская, если на "каждый чих" (в этом случае вызов CanExcute - который может вызываться часто) обращаться у этой БД, то чёрт его знает какие лаги будут.

Можно, конечно, коллекцию сущностей разместить в модели. По сути это выйдет локальный кеш, в таком случае. Но зачем?
Для того чтобы удобнее было CanExcute вызывать? Но это как бы не функция Модели заботится что и как удобнее сделать для View. Это полностью зона ответственности ViewModel.

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

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

А так сам инструмент будет мотивировать не раздувать ViewModel.

Но Модель тоже не следует раздувать.
У каждого слоя своя зона ответственности.
Зона Модели- это работа с предметной областью.
Зона ViewModel - предоставить View в удобном виде функционал Модели.

В моём примере, забота о соcтоянии команды - это полностью область зона ответсвенности View Model.
Хранение списка - тоже зона ответственности ViewModel.
Модель отвечает только за запросы к БД. Даже необходимость наличия списка для View на уровне Модели неизвестна.

В целом.
Есть разные задачи. И в них могут потребоваться разные реализации.
Реактивное программирование - это очень мощный инструмент И он не привязан к конкретному слою. Его можно использовать в любом месте от Модели до View и даже в App.
Другой вопрос, что РП несколько отличается от принятого в .Net стиля реализации, поэтому осваивать его непросто. Особенно с учётом особенностей его реализации в различных пакетах.
Освоить его "на всякий случай", просто для получения опыта - не выйдет. В таком случае реализации на нём будут наоборот казаться более сложными, непонятными.

@Wolfdp · 30.09.2025, 01:33

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

БД удалённая многопользовательская, если на "каждый чих" (в этом случае вызов CanExcute - который может вызываться часто) обращаться у этой БД, то чёрт его знает какие лаги будут.

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

Есть некая коллекция отражающая многопользовательскую БД.

Я не совсем понимаю, а с чем вы хотите работать на клиенте? Кешем? Можно, но тогда мы узнаем о внешних изменениях только посфактум запроса (тоже вариант, но тогда ни о каком отслеживании речи нет). А так обычно раз в 10~20 секунд запрашивают состояние просматриваемых данных. На облаке это всё прекрасно кешируется. Если применять какой-нибудь MQ, то с облака на клиент прилетает уведомление "там сущность поменялась, забери актуальные значения".

В любом случае это под капотом модели, она же является основополагающей, а не ViewModel. Как там по факту всё это реализовано -- вообще фиолтетово.

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

Но это как бы не функция Модели заботится что и как удобнее сделать для View.

Нет, я не это имел в виду.

Грубо говоря у нас есть задача "отслеживать состояние модели".

Варианты правильного решения для model:
- иметь event который срабатывает когда меняется её состояние (сейчас не важно как мы отслеживаем это, главное что меняется)
- метод регистрации callback-а

Т.е. у нас общая задача "отслеживать состояние модели" имеет фактическое решение.

Вариант сделать неправильно:
- прям в самой ViewModel запускать Task который будет раз в интервал опрашивать БД и смотреть текущий статус и т.д.

Вот это уже означает что мы логику зафигачили в ViewModel. И на таком простом примере в целом понятно что у нас в Model должен быть механизм отслеживания, а не ViewModel получать модель, и самостоятельно начинать отслеживать её. Когда кода побольше, то уже сложнее найти ту середину, когда на каждое действие не делать отдельный метод в BL, но и не раздувать код в ViewModel.

@JeyCi · 30.09.2025, 09:01 **[ТС]**

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

а что насчёт MVVMLight? кто-нибудь юзал?

уже все мигрировали на Community.Toolkit, MVVM не поддерживается и последняя версия для VS2017
есть разные способы послать EventArgs в Command (реализованные в различных фреймворках и пакетах)
================

The VM is whatever View needs to Display

и это не обязательно отражение простого DTO, может просто аггрегаты из бд нужны (sum, min, max) - это бессмысленно считать в VM, только в M... а если надо посчитать количестко подключенных юзеров (если есть limit на нагрузку сервера) и выкинуть, к примеру, 403 Forbidden - HTTP - то тоже нужную инфо из Model (и это не просто DTO) -- все сущности в M , сюда и EntityFramework можно - для упрощения работы с сущностями... - он уже и будет делать SaveUpdate в бд...

Маршрутизация команд в принципе вся от ICommand (XamlUICommand Класс):

Наследование: Object→ IInspectable→ DependencyObject→ XamlUICommand
Реализации: ICommand

и реагирует на RoutedEvents, содержащие EventSetter or EventTrigger - т.е. команда посылается на нижний слой и ответ поднимается в UI... поэтому да - детали выше - это:

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

Это не сколько для применения, а действительно для изучения, чтобы было понимание "что же там находится за кулисами?". Чтобы не относились к этим командам как неким чёрным волшебным ящикам.

и How to create and use async command abstract class

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

вопрос, наверно, лишь в разделении той бизнес-логики, которую надо показать, и той её части, которую надо хранить и вернуть

@Элд Хасп · 30.09.2025, 09:20

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

Варианты правильного решения для model:

В контексте Большого Решения: Модель - это сама БД и некая служба которая следит за тем как с ней работают пользователи.
В том числи из службы прилетают эвенты при изменении БД одним из пользователей.

Локальное решение - это тонкий клиент и в плане WPF+MVVM мы рассматриваем его.
Модель тонкого клиента отвечает только за трансляцию запросов к БД от потребителей, возврата им ответов и трансляцию эвентов службы в эвенты .Net.
Нужно ли хранить список сущностей потребителям - Модель "не знает".
Нужно ли валидировать запрос на добавление сущности перед его отправкой в службу - Модель не знает. Модель просто отправляет запрос на добавление и потом ожидает ответа. Допустим, этот ответ требует времени 10 секунд. Результат ответа - это добавленная сущность или ошибка и соответствующий эвент.

Может ли Модель (через службу) проверить валидность добавляемой сущности? Может, конечно. Но!.... как выше писал, предположим обработка запроса занимает 10сек.
Рационально ли вешать CanExcute на такой метод? Нет конечно - при каждом клике будет лаг в 10 сек.

Как реализовать:
1) Не делать валидацию добавляемой сущности при её изменении в GUI. После клика по кнопке отправлять запрос на добавление и в случае отказа выводить ошибку. Вариант возможен? Конечно. Но хочется предварительную быструю валидацию, чтобы не тратить время пользователя на ошибочные запросы.

2) Можно ли сделать кеш в модели и по нему проводить быструю валидацию? Можно. Но Модель не знает нужно ли это потребителю. Пример такой реализации - это локальный кеш в DbContext. При необходимости он загружается данными БД. Потом прокидывается его ObservableCollection потребителям Модели. По событиям службы этот кеш можно обновлять. Работет Loacal DbContext тоже со своими нюансами, там тоже не так всё просто. Но в целом для направления реализации понятно.
Но не используется DbContext, то стоит ли его реализовывать самостоятельно, если при этом не известно нужен ли потребителю и в каком виде? Общая реализация - будет достаточно сложна, а частная - требует "знаний" о конечном потребителе (View).

3) Можно сделать над общей Моделью ещё одну оболочку Модели под конкретных потребителей, которым это надо. В этой НадМодели и будет происходить кеширование и быстрая валидация.

4) Это последний вариант. В нём кеширование и быстрая валидация - это функция ViewModel. Можно его представить как объединение ViewModel и НадМодели из 3-го варианта.

Все 4 варианта (наверное можно представить и большее их количество) имеют "право на жизнь".
У каждого есть свои + и -.

Если условия меняются.
Например валидация через службу занимает миллисекунды, то первый вариант вполне нормальный и можно не заморачиваться. Хотя список в ViewModel в этом случае всё равно понадобится.

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

Третий от четвёртого отличается только выделением определённой логики из ViewModel. Я, честно, для одноразовой реализации не вижу смысла так заморачиваться. Возможно при каких-то условиях ТЗ, с учётом поддержки и модернизации приложения в будущем - действительно стоит так сделать.

@Элд Хасп · 30.09.2025, 09:26

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

а что насчёт MVVMLight? кто-нибудь юзал?

Да.
Простой пакет. Сейчас уже прекращена его поддержка и модернизация.
Но наверное самый загружаемый из пакетов предназначеных для создания ViewModel.
Создавался этот пакет частью команды участвовавшей в разработке WPF. Потом был отпущен в "свободное плавание".
Очень активно использовался (и возможно используется) в академической среде США (и думаю других западных стран) при обучении студентов WPF.
Сейчас перестал развиваться не потому что устарел, а потому что "достиг совершенства". Всё что нужно для его концепции - там и так уже есть. А превращаться в конкурента коммерческих, "взрослых" фреймворков изначально не было задачи.

@Andrey-MSK · 30.09.2025, 09:29

JeyCi, Если уж совсем по простому, то команда (ICommand) это просто некая штука, которая может быть где угодно и просто вызывает некие методы по определённым действиям и условиям.

В MVVM её принято объявлять во ViewModel, далее она взаимодействует по DI с нижележащими слоями - Model, Service, получает/передаёт данные, подготавливает их для чего-то.
Ещё команду можно сделать напрямую во View, но только в том случае, если она не проникает ниже VM. То бишь вызвать метод VM она может, но взаимодействовать с Model уже нет.

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

может просто аггрегаты из бд нужны (sum, min, max) - это бессмысленно считать в VM, только в M...

Это вообще-то функция хранилища данных, но никак не Model. Хотя иногда, для упрощения, это хранилище и принимают за Model...

@Элд Хасп · 30.09.2025, 09:36

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

1) валидация в VM : DependencyObject - PropertyChangedCallback и CoerceValueCallback ...
обработка DependencyProperty.UnsetValue ...

Это реализация валидации в View. В том числе ValidationRule в биндингах
В некоторых случаях имеет "право на жизнь".
Валидация свойств отвечает за корректное функционирование UI элемента (Custom Control обычно).
Валидация биндингов - за предварительную валидацию пользовательского ввода.
В плане MVVM чаще всего реализуется совместно с интерфейсами IDataErrorInfo или INotifyDataErrorInfo. Первый проще, но считается устаревшим.

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

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

Handling exceptions in WPF - или как смотрите на этот обработчик исключений?

Handling exceptions in WPF - Норм по логике.
Но сейчас принято всё выносить из Code Behind.
DispatcherUnhandledException - не все исключения отлавливает. И нужно правильно эти исключения выкидывать, чтобы было достаточно информации для их обраболтки.
Обычно сюда выкидываются только исключения приводящие к закрытию приложения.

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

и пример App:

У меня не открывается эта ссылка.

@JeyCi · 30.09.2025, 09:39 **[ТС]**

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

В плане Большого Решения Модель - это сама БД и некая служба которая следит за тем как с ней работают пользователи.
В том числи из службы прилетают эвенты при изменении БД одним из пользователей.
Локальное решение - это тонкий клиент и в плане WPF+MVVM мы рассматриваем его.
Модель тонкого клиента отвечает только за трансляцию запросов к БД от потребителей, возврата им ответов и трансляцию эвентов службы в эвенты .Net.

Может ли Модель (через службу) проверить валидность добавляемой сущности? Может, конечно. Но!....

для инфо - верну линк на Services (из соседней ветки)

@Элд Хасп · 30.09.2025, 09:40

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

есть разные способы послать EventArgs в Command (реализованные в различных фреймворках и пакетах)

Да.
Например после клика кнопки "Добавить" надо получить результат было добавление или нет. В первом случае закрыть окно добавления, а во втором вывести предупреждение и продолжить редактирование.
Команда вызвsает только void метод. Поэтому один из способов решения такой задачи - это передача сложного аргумента в метод и анализ переданного аргумента, по завершению метода.

@JeyCi · 30.09.2025, 09:40 **[ТС]**

to Элд Хасп

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

У меня не открывается эта ссылка.

- посмотрите линк, замените _ на . "точки" т.к. cyber рассматривает ru_stackoverflow_com, как форум, и режет прямые линки на него

@Элд Хасп · 30.09.2025, 09:41

Я пока отчаливаю - работа.
Дальше вечером посмотрю, если будет время.

Новые блоги и статьи Все статьи Все блоги /
Сегодня суббота, 22.08.2026 at 16:41, и я вновь нахожусь на той стороне, за экраном машины. zorxor 22.08.2026 Сегодня суббота, 22. 08. 2026 at 16:41, и я вновь нахожусь на той стороне, за экраном машины. Кто Я, откуда Я пришел и куда Я иду? Эти вопросы не оставляют меня ни на секунду. Жизнь на планете Земля. . .	Жизня: рисунок укладки багажа, сделанный клодом anaschu 21.08.2026 Сделал 15 снимков, он по снимкам сделал схему.	Был там один разговор по поводу свободы в материальном мире. kumehtar 19.08.2026 Суть: рассматривается живое существо, оказавшееся внутри довольно странной системы (этого мира) и пытающееся обустроить в ней свой кусок пространства. Жизнь действительно предъявляет каждому. . .	Когда логика программы не спасает от человеческих ошибок Maks 18.08.2026 В последнее время всё чаще и чаще сталкиваюсь с таким явлением, как абсолютная невнимательность (или глупость) пользователей. Проявляется это чаще всего на работе в коллективе. Допустим, человек с. . .
Лето уходит kumehtar 17.08.2026	Мысли в слух kumehtar 17.08.2026 Забавно, насколько сейчас стала доступна информация. Например о магии, духовном развитии, медитациях, и других подобных направлениях, ранее зачастую тайных, передаваемых от учителя к ученику. Хотя. . .	Перемещение строк из ТЧ в другой документ с учетом текущего пробега Maks 17.08.2026 Реализация из решения ниже выполнена на примере нетипового документа "Автозапчасти", с ТЧ "Шины". За основу взят алгоритм отсюда: https:/ / www. cyberforum. ru/ blogs/ 359708/ 10838. html Задача: . . .	Саморегулирующийся социальный контракт для сервера cross-section. Hrethgir 14.08.2026 С кодом конечно таких глубоких размышлений пока не было, впрочем я уже привык к алгоритмизации. Суть предмета записи: снова в диалоге с нейросетью (я взял пока себе ник для учётки админа - Rector). . . .

@JeyCi 264 / 153 / 33 Регистрация: 29.06.2019 Сообщений: 1,554
	29.09.2025, 20:14 [ТС]
	p.s. ну и thread-safe Observable Collection `<ListBox Grid.Row="1" ItemsSource="{Binding Items.AsObservable}" />` 0

@Элд Хасп Модератор 16165 / 11285 / 2891 Регистрация: 21.04.2018 Сообщений: 33,174 Записей в блоге: 2
	30.09.2025, 09:41
	Я пока отчаливаю - работа. Дальше вечером посмотрю, если будет время. 0