MVVM открытие вторичного окна с передачей параметра в конструктор ViewModel

Uswer · Регистрация: 26.06.2017

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

Добрый день.

Тема наверняка избита, поэтому заранее прошу сильно не пинать. Если что, то я честно искал инфу и на форуме, и вообще.

Проблема, которую мне хотелось бы обсудить: это открытие вторичного окна в паттерне MVVM с передачей через конструктор ViewModel параметра. Алиса говорит, что сделать это используя XAML невозможно. Значит надо это делать как-то иначе. Вариантов решения я нашёл аж три: 1. Создание сервиса или фабрики, который создаёт и окно, и связанную с ним VM, а при необходимости может даже инжектить объекты в VM. 2. Использование code-behind и свойств окна. 3. Использование ObjectDataProvider. Но всё равно возникает трудность с передачей параметра, т.е. нужен прокси-объект, который будет предоставлять параметр извне.

В ходе недавнего обсуждения в этой теме я принял решение вынести проверку критически важных настроек приложения непосредственно в App.xaml.cs. И вот тут вопрос этой темы встал остро. Дело в том, что VM окна настроек, которое я планирую показывать в случае обнаружения ошибок в критически важных настройках, должна получить некий сервис. Логично чтобы это выглядело так

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

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
  public partial class App : Application
  {
     void App_Startup(object sender, StartupEventArgs e)
     {
         mSettings appSettings = new mSettings();
         appSettings.LoadSettings();
 
         mSettingsInspector inspector = new mSettingsInspector(); // отвечает за проверку настроек
 
         if (inspector.TryCheckSettings(appSettings))
         {
           MainWindow mainWindow = new MainWindow();
           mainWindow.Show();
         }
         else
         {
           SettingsWindow settingsWindow = new SettingsWindow();
           settingsWindow.Show();
         }
     }
  }

В данном примере подразумевается, что создание VM происходит в xaml.
В данном случае нет внедрения в VM окон ничего хотя по заданию это должно происходить.
С учётом того, что App видит все слои MVVM можно изменить код так:

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

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
  public partial class App : Application
  {
     void App_Startup(object sender, StartupEventArgs e)
     {
         mSettings appSettings = new mSettings();
         appSettings.LoadSettings();
 
         mSettingsInspector inspector = new mSettingsInspector(); // отвечает за проверку настроек
 
         if (inspector.TryCheckSettings(appSettings))
         {
           MainWindow mainWindow = new MainWindow();
           mainWindow.Show();
         }
         else
         {
           var dataService = new mDataService();
           var vm = new SettingWindowViewModel(appSettings, dataService);
           var settingsWindow = new SettingsWindow();
           settingsWindow.DataContext = vm;
           settingsWindow.Show();
         }
     }
  }

Насколько это правильный подход для MVVM?

И главный нюанс, который не даёт покоя: если на старте программы проверить настройки не проблема, то в ходе работы и в случае изменения настроек, надо реконфигурировать практически всё приложение. При этом у нас есть VM главного окна из которой надо открывать вторичные окна с передачей в их VM сервисов, а это уже намного сложнее.
Как же это делается? По варианту №1? Если да, то к какому слою в паттерне MVVM относится сервис знающий и об окнах, и об их VM, и, возможно, об модели?

@wizard41 · 06.06.2025, 22:25

Uswer, честно, у меня были точно такие же проблемы. Но, как-то разрешились, и(!) даже без особого задавания вопросов на форуме. Все почему - потому что слушал и изучал примеры более опытных коллег:

Добавлено через 1 минуту
Wolfdp
Элд Хасп
kolorotur
...

Uswer · 06.06.2025, 22:30 **[ТС]**

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

потому что слушал и изучал примеры более опытных коллег

Я делаю ровно тоже самое, но с ма-а-аленьким отличием - не применяю готовых решений вроде Microsoft.Extensions.DependencyInjection . И, как ты надеюсь понимаешь, это в разы всё усложняет.

@wizard41 · 06.06.2025, 22:32

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

это в разы всё усложняет.

Конечно. Не зная броду - лезем в воду...

Uswer · 06.06.2025, 22:38 **[ТС]**

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

Не зная броду - лезем в воду...

А не полезешь в воду, так реку никогда и не пересечёшь.

Добавлено через 57 секунд

Не по теме:

Давай флидуть будем поменьше. Я тоже постараюсь себя сдерживать.

Добавлено через 3 минуты
Кстати, что по вопросу:
И как часто меняется фреймворк фронта?

@wizard41 · 06.06.2025, 22:40

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

так реку никогда и не пересечёшь.

В каком-то смысле да. Но, опять же, надо брать ношу по себе. Чтоб не падать при ходьбе (С)

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

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

И как часто меняется фреймворк фронта?

Лично я не в курсе. Это делают где-то там.. Но пока о проблемах не сообщали.. Да и вроде как моя часть обязательств не коррелирует с этим.

@Wolfdp · 06.06.2025, 23:35

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

Если не затруднит, то проясните это.

Окей....

Для начала, в слой "view-model" входять непосредственно эти самые %Name%ViewModel, а также ICommand. Все действия от пользователя выносятся в ICommand. Вызов окна настроек -- тоже действие пользователя. %Name%ViewModel -- это больше для отображения информации, связи вводимых данных через Binding и размещения этих самых ICommand на View опять же через Binding (логику тоже можно закидывать, но стоит избегать такого).

Теперь разбираем непосредственно реализацию ICommand -- это обычный класс (можно и структуру, но это бессмысленно). А значит мы можем в него прокинуть любой внутренний сервис в виде interface. В нашем случае скажем это

C#
1
2
3
4
    public interface IWindowService
    {
        public void ShowSetting();
    }

Непосредственная реализация это уже уровень App, т.к. нужно знать об view-model, view, а при использовании DI ещё всё это зарегестрировать и скорее всего запаковать в фабрику. В теории это можно спихнуть на уровень view, т.к. он всё же должен ориентироваться на view модел. Вам нужно понять только одно -- внутри view-model супер-абстрактный интерфейс, а кто и как там вызывается -- не забота этой самой view-model. Тут даже не сколько правильность MVVM, сколько банальная логика разделения ответственности.

Теперь сама реализация IWindowService

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
internal class WindowService : IWindowService
{
    private readonly IViewModelsService _viewModelsService;
    private readonly IViewModelFactory _viewModelFactory;
 
    public WindowService(IViewModelsService viewModelsService,
                         IViewModelFactory viewModelFactory)
    {
        _viewModelsService = viewModelsService;
        _viewModelFactory = viewModelFactory;
    }
 
    public void ShowSetting()
    {
        // создаем view-model, считайте что аналог такого // viewModel = new SettingsViewModel();
        var viewModel = _viewModelFactory.CreateViewModel<SettingViewModel>();
        // создаем окно, считайте что в аналог такого // window = new SettingsWindow();
        var window = _viewModelsService.GetWindow(viewModel);
        window.DataContext = viewModel; //привязываем view-model к view
        window.Show(); //показываем не модально
    }
}

IViewModelsService и IViewModelFactory -- это части DI. Нам не важно что за ними, основная идея в том что все new в идеале должны происходить либо в ioc-container, либо в factory. Если гляните пример от Andrey-MSK, то там есть сначала проверка что окно уже не открыто путём перебора Application.Current.Windows (удобно, но в идеале стоит в самом IWindowService хранить это значение), и саму view-model подразумевает создавать на внешнем коде (осуждаю, но это тема больше для холивара). Плюс россыпь MessageBox.

Теперь представим что вам вместо окна нужно показать UserControl на MainWindow. ViewModel, ICommand -- всё это остается без единого изменения. В View вы тупо копируете весь xaml из windows в usercontrol. Меняете в WindowService реализацию метода ShowSetting. Вы только что сделали рефакторинг приложения за 5 минут без напряга и на 146% уверены что ничего не сломали (тестировать всё равно придётся).

Не по теме:

Замечу что всё это в целом можно провернуть и без MVVM и DI. Просто создать отдельный класс, который будет делать ShowSettings, и прям его без всяких интерфесов скажем через static singeltone дергать тупо по Button.Click прям в code-behind. Но для таких "простых" мувов нужно иметь адски правильное представление об общей архитектуре, т.к. любой шаг в сторону -- и все начинает ломаться. Поэтому пишут "сложно". Ну и поддерживать такое не очень удобно, даже в одно лицо.

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

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

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

не применяю готовых решений вроде Microsoft.Extensions.DependencyInjection

Вот это очень плохая идея. Некоторые вещи велосипедить не стоит от слова "совсем". DI, на мой скромный взгляд, входит в их число.

На либе MS свет не сошёлся, есть всякие Autofac, Ninject, Spring.Net и ещё наверное с десяток.

@Элд Хасп · 07.06.2025, 13:49

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

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

не применяю готовых решений вроде Microsoft.Extensions.DependencyInjection

Вот это очень плохая идея. Некоторые вещи велосипедить не стоит от слова "совсем". DI, на мой скромный взгляд, входит в их число.

Ну,...
Здесь две разные задачи.
1) Академическая по изучению WPF, MVVM и т.п.
2) Создание приложения для распространения.

В первом случае использование своих кастомных реализаций INPC, команды, внедрение зависимостей вполне оправдано.

@Элд Хасп · 07.06.2025, 20:40

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

Всё что кардинально отличает WPF от WF это привязки внедрённые во всё и присоединяемые свойства. Остальное лишь пересмотр прежних решений, как например переход на DirectX и отказ от GDI+. Ну тут просто людям стало понятно, что это устарело, а следовательно медленно и неудобно. И это напрочь скрыто от разработчика, если он не лезет в самое нутро конечно.

1) Привязки появились ещё в Формах. Но там они требуют "ручного кода", поэтому, используются только достаточно опытными пользователями. В целом встречаются крайне редко.
В WPF (любой XAML платформе) привязки внедрены уже как основной способ связывания UI элементов с источниками данных. Хоть использование привязок не является обязательным, но их использование очень просто и не вызывает затруднения даже у начинающих. Но привязки потянули за собой и более строги требования к архитектуре приложения: для привязок нужны правильно подготовленные источники данных. Как оказалось, даже для многих опытных пользователей их знания ООП архитектуры были формальны и на практике вызвало достаточно большие сложности в реализации MVVM.
Но из моего личного опыта, те кто писал Формы с правильной реализованной архитектурой MVP, никаких сложностей с переходом на MVVM не испытывал.

2) Что вы имеете ввиду за сложности с присоединёнными свойствами - воще, не понял.
Все DependencyProperty - это присоединённые свойства (Attached Property).
Часть из них объявляется в DependencyObject и ограничивается использование в этом типе и его наследниках. Вот эти обычно называются Dependency Property (обратите внимание что здесь есть пробел).
Другие могут объявляться в любом типе и использоваться любым типом DependencyObject. Вот их обычно называют Attached Property.
В синтаксисе атрибут для обращения к Attached Property требует полного имени OwnerType.Property. Но к Dependency Property можно так же обращаться.
Так как для Dependency Property известно, что они объявлены в этом типе UI элемент, то указывать тип не обязательно и можно использовать просто имя свойства.

XML
1
2
    <TextBlock Text="{Binding}"/>
    <TextBlock TextBlock.Text="{Binding}"/>

В остальном нет между ними никакой разницы.

3) "Остальное"... соглашусь, что "железная" часть платформы большинству разработчиков не интересна. Но само себе введение отдельного языка XAML для разметки GUI - это огромный шаг вперёд в сравнении с Формами. Ведь это только сам XAML, это все инструменты необходимые для того чтобы XAML было достаточно для компоновки интерфейса: "резиновость" элементов, Шаблоны и Стили элементов, Шаблоны Данных, Конвертеры, Анимации и мн. др.

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

Готового решения пока нет ни по одному вопросу. Я кручу-верчу код туда-сюда постоянно наступая на разные грабли.

"Крутите вертите" с какой целью?
Попробовать разные варианты для получения опыта, знаний?
Или предложенные варианты решения не устраивают по той или иной причине?

@Элд Хасп · 07.06.2025, 20:57

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

присоединяемые свойства

Подумал, возможно у вас трудности возникли из-за различий в использовании Dependency Property и Attached Property в коде Шарпа?

C#
1
2
grid.Width=123;
grid.SetColumn(textBlock, 1);

В данном примере ни grid.Width не является Dependency Property, ни grid.SetColumn не является Attached Property.
И то и другое это статические поля в типе:

C#
1
public static readonly DependencyProperty SomeProperty = DependencyProperty.Register....;

И к тому и другому обращаются через методы DependencyObject.Set/GetValu(...).
А CLR свойство и метод - это просто оболочки упрощающие для разработчика обращения к DependencyProperty.

Добавлено через 7 минут
Где находятся поля, хранящие значения свойств зависимости (DependencyProperty)?

@wizard41 · 07.06.2025, 22:55

Uswer, Careless..

@Wolfdp · 08.06.2025, 00:01

Не по теме:

Но само себе введение отдельного языка XAML для разметки GUI - это огромный шаг вперёд в сравнении с Формами

Жалко только что единственный. Что там поменялось со времён 4.5? Правильно -- ничего. Если брать в аналоги тот же asp.net mvc razor, то он с крайне убогих тегов модифицировался в довольно лаконичный вариант отдалённо напоминающий T4. Один только факт что View можно жестко завязать на тип Model и тем самым компилятор сразу скажет что ты провмыкал синтаксис. В WPF даже в рантайме ошибку не получишь.... грустно всё это.

@wizard41 · 08.06.2025, 00:12

Wolfdp, декларативный язык, пришедший со времен, когда веб-страницы в блокноте верстали. И не плохо развился, стоит заметить.

@Элд Хасп · 08.06.2025, 00:14

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

Что там поменялось со времён 4.5? Правильно -- ничего.

Я сам не пойму политику MS в отношении WPF.
Есть удобный инструмент, с огромной поддержкой в среде разработчиков.
Но почему в самой MS он как "нелюбимое дитя". Не хотят его развивать и всё!
Вцепились в UWP и пытаются его продвинуть несмотря ни на что.
UWP "не зашло" разработчиками. Платформа ужасно убогая в сравнении с WPF.
Выдернули из него GUI и пытаются впихивают его под новым названием WinUI. Но как был убогим, так и остался.

Uswer · 08.06.2025, 10:58 **[ТС]**

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

"Крутите вертите" с какой целью?

Всё прозаично - основной функционал был успешно разработан на "классах-заглушках", причём достаточно быстро это получилось сделать даже с учётом написания самих заглушек. Но когда я стал подключаться к реальным сервисам, то обработка самых различных аварийных ситуаций раздула код в разы. А чем больше кода, тем больше нестыковок. И этот снежный ком только разрастается. Одну из возникших проблем я уже озвучивал на форуме, это когда из-за неправильных настроек одного сервиса другой сервис тоже нельзя сконфигурировать. Я понимаю, что для людей, которые разработкой занимаются постоянно и это их хлеб, такие ситуации являются рядовыми, но для меня это всё достаточно сложно. Усугубляется всё тем, что занимаюсь кодингом урывками и часть времени тратится на то, чтобы вспомнить что к чему. В конечном итоге я безусловно разберусь. Если энтузиазма хватит, то при рефакторинге текущей софтины библиотеки буду использовать и всё такое.
К большому сожалению чистого MVVM у меня не получилось, возможно в следующем проекте буду делать это строже.

Элд Хасп, с присоединяемыми свойствами всё хорошо в плане понимания. Я говорил о том, что одна строчка в XAML превращается в тучу строк C#. И как мне кажется именно поэтому мелкомягкие придумали XAML, т.е. чтобы избавить разработчика от жуткой рутины.

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

Вцепились в UWP и пытаются его продвинуть несмотря ни на что.

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

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

под новым названием WinUI. Но как был убогим, так и остался.

А может вы пока не понимаете всех прелестей этой технологии? И сейчас у вас точно такая же ситуация по преодолению порога вхождения, как у меня с MVVM. (гипотеза)

@Элд Хасп · 08.06.2025, 12:35

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

А может вы пока не понимаете всех прелестей этой технологии? И сейчас у вас точно такая же ситуация по преодолению порога вхождения, как у меня с MVVM. (гипотеза)

В том и дело что все "прелести" уже прочуствовал.
UWP (и другие XAML) приходится использовать из-за отсутствия WPF на других платформах.
И каждый раз как натыкаюсь на очередную "прелесть" тихо матерюсь.
То что можно сделать на WPF "одной строкой" на UWP часто требует основательных "танцев с бубном".
Единственно, что существенно добавили в UWP - это компилируемые привязки x:Bind.
В WPF их тоже обещали добавить, но "воз и ныне там".
Да, и за эти годы их актуальность стала уже почти нулевой.
Они дают ускорение. UWP рассчитан на различные устройства. И на слабых устройствах - это ускорение могло давать существенный выигрыш.
Но за 15 прошедших лет изменилось понимание что такое "слабое устройство".
Сейчас даже на самых слабых устройствах никакого реального преимущества компилируемые привязки в сравнении с обычными не дадут. Выявить разницу удастся только какими-то синтетическими тестами.

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

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

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

Маркетологи, бизнес ассистенты и т.п.
Для них огромный плюс UWP - это распространении этих приложений через Microsoft Store.
Этот плюс перевешивает все недостатки вместе взятые.
Голоса инженеров, разработчиков решающей роли не играют.

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

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

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

Ну, это не проблема WPF.
Это задача уровня Бизнес Логики и App.

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

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

Это для всех не просто.
Чтобы упорядочить всю эту кашу и приходится использовать какие-то паттерны, типовые решения, распространённые фреймворки и т.д.
Но главное это умение "в голове" разделить большую задачу на мелкие, их на пошаговые алгоритмы, построить на всём этом какую-то адекватную архитектуру.

Конкретно с настройками изменяющимися динамически - основа очень проста.
Настройки для бизнес логики - это такие же данные как и все остальные.
Если они меняются значит нужно какое-то уведомление об этом.
Если меняются они только в рамках сеанса одного приложения, то локальный класс провайдер обслуживающий их.
Если меняются в многопользовательском режиме, то уже, возможно, потребуется какая-то служба для отслеживания.
В любом случае на уровне бизнес логики появляется какой-то объект поставщик данных (пусть и настроек). При изменении данных в нём поднимается событие. Потребители данных подписаны на поставщика и по событию обновляют своё состояние. Потребители могут быть любого уровня: Model, View, Controller, Presenter, ViewModel и т.д. Для Поставщика нет разницы кто потребляет его данные.

@Wolfdp · 08.06.2025, 16:00

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

Это задача уровня Бизнес Логики и App.

+1

В теории внутрянка должна быть настолько независима, что можно вытянуть и без радикальных изменений вставить например в WinForms. Я за ориентир обычно беру возможность вынести всё это добро в отдельную либу.

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

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

Вот кстати это желание "учесть отражение света газов Венеры от колец Сатурна" стоит пресекать на проекте.

Все силы в первую очередь должны идти на штатную работу приложения. Т.е. считаем что все сервисы сконфигурированы, всё подключается, всё работает.

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

Uswer · 08.06.2025, 17:01 **[ТС]**

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

обычный юзер пойдёт в техподдержку

То есть опять обратится ко мне

@Wolfdp · 08.06.2025, 17:24

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

То есть опять обратится ко мне

Я не особо понимаю в чём проблема с конфигами. Они так часто правятся?

Uswer · 09.06.2025, 07:53 **[ТС]**

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

Они так часто правятся?

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

@Wolfdp · 09.06.2025, 18:26

Uswer, им нужно будет вбивать эти настройки самостоятельно, или это тоже ваша ответственность? Если ваша -- вынесите всё в конфиг файлы (причём можно задать нетипичное расширение, например *.sys), уберите окна настроек чтобы не провоцировать юзверей поиграть в админов и у вас резко поубавится работы.

Если адресса серверов таки должны вбивать пользователе -- вы не защититесь от "неправильных" значений никак, и валидация должна присутствовать много где. Типа стартуем сервис -- сначала проверяем что конфиги адекватны. Это же опять не уровень WPF.

Новые блоги и статьи Все статьи Все блоги /
ИИ не может найти нужный язык в списке Supersumestria 05.10.2026 Я ему даю вот такое изображение и прошу найти и подчеркнуть немецкий язык. Возвращает он вот это: https:/ / i. **********/ vqBWLe2. png Нужную строчку в 3й колонке просто выдумал. . Это. . .	Новая последняя моя музыка в SUNO zorxor 05.10.2026 Здравствуйте, дорогие мои друзья! С большой радостью я хотел бы представить вам свою новую последнею музыку, которую сгенерировала мне по моей просьбе нейросеть SUNO. С уважением, zorxor. Это. . .	Программный домашний кинотеатр russiannick 27.09.2026 Сподобился на программный домашний кинотеатр. В качестве ЯВУ по традиции выбрал js. В помощники взял Яндекс-Алису. Было создано три зала на разные интересы. исторические и ретро сериал Хичкок. . .	Беседа с ИИ о программистах, недопускающих к созданию и правке кода генеративные ИИ и причины этого zorxor 21.09.2026 Раньше я радовался или получал некоторые эмоции, пусть небольшие, но всё же, от самого процесса написания кода, рекомпиляции и запуска, видя постепенное развитие программы и прочее. А теперь лень. . .
Мобильное приложение 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. Опрашиваются регистры. . .

@wizard41 3463 / 2784 / 575 Регистрация: 04.09.2018 Сообщений: 8,757 Записей в блоге: 3
	06.06.2025, 22:25
	Uswer, честно, у меня были точно такие же проблемы. Но, как-то разрешились, и(!) даже без особого задавания вопросов на форуме. Все почему - потому что слушал и изучал примеры более опытных коллег: Добавлено через 1 минуту Wolfdp Элд Хасп kolorotur ... 0

@wizard41 3463 / 2784 / 575 Регистрация: 04.09.2018 Сообщений: 8,757 Записей в блоге: 3
	07.06.2025, 22:55
	Uswer, Careless.. 0

@wizard41 3463 / 2784 / 575 Регистрация: 04.09.2018 Сообщений: 8,757 Записей в блоге: 3
	08.06.2025, 00:12
	Wolfdp, декларативный язык, пришедший со времен, когда веб-страницы в блокноте верстали. И не плохо развился, стоит заметить. 0

@Wolfdp 3790 / 1767 / 371 Регистрация: 15.06.2012 Сообщений: 6,543 Записей в блоге: 3
	09.06.2025, 18:26
	Uswer, им нужно будет вбивать эти настройки самостоятельно, или это тоже ваша ответственность? Если ваша -- вынесите всё в конфиг файлы (причём можно задать нетипичное расширение, например *.sys), уберите окна настроек чтобы не провоцировать юзверей поиграть в админов и у вас резко поубавится работы. Если адресса серверов таки должны вбивать пользователе -- вы не защититесь от "неправильных" значений никак, и валидация должна присутствовать много где. Типа стартуем сервис -- сначала проверяем что конфиги адекватны. Это же опять не уровень WPF. 0