K>Короче, судя по ответам, я был прав

Ты прав, иди с миром. Ни дай бог с тобой на проекте быть.

Здравствуйте, Kolesiki, Вы писали:

K>Ребят, интересный вопрос в свете "декларативного ГУЯ" и WPF в частности.

K>Допустим, есть бизнес-задача, где есть ряд однотипных окон (скажем, диалоги и у всех OK/Cancel).
K>Логично было бы, как мастодонты ООП, заделать базовый MyWindow, где есть кнопки OK/Cancel, а однотипные окна унаследовать от этого самого MyWindow и накидать нужные дополнительные редакторы.
K>А вот фигушки! 'MyWindow' cannot be the root of a XAML file because it was defined using XAML.
K>Получается, сели мы с этой декларативностью в лужу! Хотя вопрос-то принципиально разрешимый — в том же Delphi можно было спокойно наследовать окна и дополнять контролами.

K>Может, и в WPF можно заделать какую-никакую наследуемость? Скажем:

K>

K><Window>
K>    <PlaceholderForInheritors />
    
K>    <Button>OK</>
K></>
K>

K>...и тогда VS будет вместо PlaceholderForInheritors давать редактор для внутренних тегов!
K>Понятно, что это костыль и кто-то даже захочет что-то вставить ПОСЛЕ кнопки ОК, но тут уж решать — либо космические архитектуры, либо вполне простое решение 99% проблем.

Это решается контролами. На пустую форму с двумя базовыми кнопками помещается требуемый контрол и все.
В Делфи для этого использовались фреймы.

Ещё один сугубо практический момент задачи:

Допустим даже, что мы вместо прямого решения средствами ООП, забацали чисто WPF-ный костыль "Окно + внутри кастомные контролы".
Но тогда нам нужно решить ещё одну задачу — доступ из контрола к "инфраструктуре" окна-владельца! Потому что если ты захочешь из контрола показать модальное окно, тебе надо будет задать у модального окна Window.Owner — а вот фигушки, из контрола нет (прямого) доступа к окну, на котором он лежит! Т.е. опять костыли — придётся лепить интерфейс, который будет у всех контролов и где можно получить доступ к окну-владельцу. Ну спасибо, чо! Мне ж больше не на что тратить время, кроме как городить хелперы для обхода неуклюжего WPF!

Короче, судя по ответам, я был прав — при разработке WPF на ООП вообще забили — налепили декларативной (и overengineered) шняги, а как ею пользоваться... ну вот же, кнопочки кастомайзятся! "Чего тебе ещё надобно, собака?!" (ц) ИВМП
Смешно сказать — в декларативном файле, который даже в сборку не попадает, нельзя использовать #if ! Зато у нас "облака" и дебильный git.

Здравствуйте, Kolesiki, Вы писали:

K>Допустим, есть бизнес-задача, где есть ряд однотипных окон (скажем, диалоги и у всех OK/Cancel).
K>Логично было бы, как мастодонты ООП, заделать базовый MyWindow, где есть кнопки OK/Cancel, а однотипные окна унаследовать от этого самого MyWindow и накидать нужные дополнительные редакторы.

Нелогично. Такой подход применялся до 90х и даже до 00х, ничего хорошего из этого не вышло.
Это как раз то самое противоестественное наследование, от которого всегда куча проблем. Например, в каком то наследнике придется убрать Ok или Cancel и оставить всё остальное. Упс.
Именно форму-с-контролами наследовать не нужно, это делается композицией.

Ребят, интересный вопрос в свете "декларативного ГУЯ" и WPF в частности.

Допустим, есть бизнес-задача, где есть ряд однотипных окон (скажем, диалоги и у всех OK/Cancel).
Логично было бы, как мастодонты ООП, заделать базовый MyWindow, где есть кнопки OK/Cancel, а однотипные окна унаследовать от этого самого MyWindow и накидать нужные дополнительные редакторы.
А вот фигушки! 'MyWindow' cannot be the root of a XAML file because it was defined using XAML.
Получается, сели мы с этой декларативностью в лужу! Хотя вопрос-то принципиально разрешимый — в том же Delphi можно было спокойно наследовать окна и дополнять контролами.

Может, и в WPF можно заделать какую-никакую наследуемость? Скажем:

<Window>
    <PlaceholderForInheritors />
    
    <Button>OK</>
</>

...и тогда VS будет вместо PlaceholderForInheritors давать редактор для внутренних тегов!
Понятно, что это костыль и кто-то даже захочет что-то вставить ПОСЛЕ кнопки ОК, но тут уж решать — либо космические архитектуры, либо вполне простое решение 99% проблем.

Так или иначе, факт тот, что при всех приятностях декларативности, она проваливается даже на самом базовом принципе ООП.

Здравствуйте, Kolesiki, Вы писали:

K>Ребят, интересный вопрос в свете "декларативного ГУЯ" и WPF в частности.

K>Допустим, есть бизнес-задача, где есть ряд однотипных окон (скажем, диалоги и у всех OK/Cancel).
K>Логично было бы, как мастодонты ООП, заделать базовый MyWindow, где есть кнопки OK/Cancel,

Расширение наследованием не единственный и не самый удобный способ. Только упоротые мастодонты все подряд наследуют. Минус этого, банально, что ты не расширишь окно которое уже унаследовано от чего то другого.
Более гибким является навешивание поведения снаружи (Behavior, attached properties,...). Наследование уместно когда требуется оверайдить виртуальный метод.


K>А вот фигушки! 'MyWindow' cannot be the root of a XAML file because it was defined using XAML.

Не понял откуда ты это взял. Можно запросто сделать наследника MyWindow:Window и юзать этот MyWindow в разметке.
Я даже для кастомных контролов больше не юзаю UserConrol, сразу наследника от Grid например делаешь и готово, это немного ускоряет разгрузку UI.

K>>>Ребят, интересный вопрос в свете "декларативного ГУЯ" и WPF в частности.

K>>>Допустим, есть бизнес-задача, где есть ряд однотипных окон (скажем, диалоги и у всех OK/Cancel).
K>>>Логично было бы, как мастодонты ООП, заделать базовый MyWindow, где есть кнопки OK/Cancel,

_>>Расширение наследованием не единственный и не самый удобный способ. Только упоротые мастодонты все подряд наследуют.

K>Ясно. Ты из тех стоматологов, которые вместо лечения зубов предлагают перейти на манку. Извините, такой тупейший способ абсолютно неинтересен.

Нет, это ты из тех проктологов которые все лечат через задний проход. И кто лучше? Подсказка — оба нужны.

_>>Более гибким является навешивание поведения снаружи

K>Мне не нужна гибкость или какие-то упоротые attached properties. Я хочу общий класс и наследников.

_>> Наследование уместно когда требуется оверайдить виртуальный метод.

K>И кто тебе сказал, что у меня его нет?

Тогда у тебя нет проблем — вперед, ты знаешь сам все ответы.


K>>>А вот фигушки! 'MyWindow' cannot be the root of a XAML file because it was defined using XAML.

_>>Не понял откуда ты это взял. Можно запросто сделать наследника MyWindow:Window и юзать этот MyWindow в разметке.

K>Непонятно, с чего ты решил, что это можно. Видимо, на практике ты этого никогда не делал.
K>Создай окно, положи на него кнопку (ну или в XAML сбацай). Теперь создай второе окно и унаследуйся от первого. Как только получишь ошибку как у меня, приходи обсуждать.

Почувствуй разницу между "нельзя" и "не умею". Правильно то что это и не надо делать. Кактус — он колется если его жрать.
Ты путаешь наследование в коде и разметку. Разметка в принципе не наследуется. Головешку свою включи и подумай, как бы выглядел унаследованый UserControl _с_разметкой_. В разметке что? Новая наследника старая базового? Ни то ни другое. В WinForms тоже можно было наследовать формы и юзерконтролы. Только боль от этого была в перспективе жуткая.

K>Насколько я вижу, WPF тут лажает по полной.

Насколько я вижу у топикстартера ООП мозга. Он в принципе не понимает как это так что ООП молотком ни все забивается
Ну давай еще разжуем. Представь 3 окна. По части фукнционала (т.е. в коде) все одинаково. Но внешний вид разный. И что твой ООП должен делать, что наследовать?
А наследуется ведь только код, конкретные классы. Выходит ты создал бы наследников _только_ ради изменения разметки. Но зачем если можно просто указать другуя разметку.
Просто для этого ни надо юзать USerControl. Для этого есть другой патерн в WPF: создание кода контрола и разные шаблоны. Тебя огорчает что под шаблоны нет такова же дизайнера в студии? Да, это упущение, UserControl легче дизайнить. Но это недостаток тула, студии, и никак ни технологии WPF. К тому же есть Blend, может там проблема решена.

Здравствуйте, Kolesiki, Вы писали:

K>Ещё один сугубо практический момент задачи:

K>Допустим даже, что мы вместо прямого решения средствами ООП, забацали чисто WPF-ный костыль "Окно + внутри кастомные контролы".
K>Но тогда нам нужно решить ещё одну задачу — доступ из контрола к "инфраструктуре" окна-владельца! Потому что если ты захочешь из контрола показать модальное окно, тебе надо будет задать у модального окна Window.Owner — а вот фигушки, из контрола нет (прямого) доступа к окну, на котором он лежит! Т.е. опять костыли — придётся лепить интерфейс, который будет у всех контролов и где можно получить доступ к окну-владельцу. Ну спасибо, чо! Мне ж больше не на что тратить время, кроме как городить хелперы для обхода неуклюжего WPF!

K>Короче, судя по ответам, я был прав — при разработке WPF на ООП вообще забили — налепили декларативной (и overengineered) шняги, а как ею пользоваться... ну вот же, кнопочки кастомайзятся! "Чего тебе ещё надобно, собака?!" (ц) ИВМП
K>Смешно сказать — в декларативном файле, который даже в сборку не попадает, нельзя использовать #if ! Зато у нас "облака" и дебильный git.

Я просто надеюсь, что мне никогда не придётся поддерживать код подобного вот любителя своего выдуманного ООП.
Удивляет даже, что разговор про WPF, а не какой-нибудь MFC.
И WPF такое себе поделие, но и вот это всё

Здравствуйте, Kolesiki, Вы писали:

K>Здравствуйте, barn_czn, Вы писали:

_>>Ну давай еще разжуем. Представь 3 окна. По части фукнционала (т.е. в коде) все одинаково.

K>нет. В коде тоже будут различия — переопределённые методы, свои методы.

Тогда это уже другой функционал, другой класс. А разметка она снова своей жизнью живет. Может та же остаться может нет. Вдупли уже, что разметка и код живут разной жизнью. У них есть точки сопряжения через имена и все. И ООП тут вообще не причем.

_>> Но внешний вид разный. И что твой ООП должен делать, что наследовать?

K>Всё — внешний вид и поведение.

Давай, покажи мне как унаследовать голый xaml.

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

K>Белиберда полная — учись выражать мысли. Просто посмотри, что я предложил в топике — там пусть и убогонькое, но наследование UI — собсно, его за глаза достаточно.

Я вижу ты мастер самовыражения. Предложил он. Я просил тебя мне чтото предлагать? Или ты сам высосал проблему и сам ее мужественно решил? Ну молодец, тогда нет проблемы расходимся.

K>Создай окно, положи на него кнопку (ну или в XAML сбацай). Теперь создай второе окно и унаследуйся от первого. Как только получишь ошибку как у меня, приходи обсуждать.

Присоединяюсь к вашему вопросу. Использовал и использую как и Delphi, так и WinForms, так и WPF. Вопрос как наследовать "целые окна в WPF" -- я для себя не решил.

Вот пример исходного кода, https://github.com/KohrAhr/Rsdn09Apr2020/ который воспроизводит вашу ошибку: "Error 'Rsdn09Apr2020.Forms.Base.BaseCommonWindow' cannot be the root of a XAML file because it was defined using XAML. Line 1 Position 21. Rsdn09Apr2020 source\repos\Rsdn09Apr2020\MainWindow.xaml 1"

Visual Studio 2017.

Очень хотелось бы услышать, как можно это реализовать. Спасибо!

K>либо космические архитектуры, либо вполне простое решение 99% проблем.
В старину недолго существовало такое интересное явление, как Delphi8 и VCL.Net — там сделали возможность в VCL'ной форме (dfm), с её полностью работоспособным визуальным наследованием, использовать в контролах нетовские источники данных (DataTable и т. п.) Но, увы, "спектакль прошёл успешно, а вот публика провалилась".

Здравствуйте, barn_czn, Вы писали:

_>Здравствуйте, Kolesiki, Вы писали:

K>>Ребят, интересный вопрос в свете "декларативного ГУЯ" и WPF в частности.

K>>Допустим, есть бизнес-задача, где есть ряд однотипных окон (скажем, диалоги и у всех OK/Cancel).
K>>Логично было бы, как мастодонты ООП, заделать базовый MyWindow, где есть кнопки OK/Cancel,

_>Расширение наследованием не единственный и не самый удобный способ. Только упоротые мастодонты все подряд наследуют.

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


_>Более гибким является навешивание поведения снаружи

Мне не нужна гибкость или какие-то упоротые attached properties. Я хочу общий класс и наследников.

_> Наследование уместно когда требуется оверайдить виртуальный метод.

И кто тебе сказал, что у меня его нет?


K>>А вот фигушки! 'MyWindow' cannot be the root of a XAML file because it was defined using XAML.

_>Не понял откуда ты это взял. Можно запросто сделать наследника MyWindow:Window и юзать этот MyWindow в разметке.

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

AA>Если бы это был не xaml, а обычный код

Если бы да ка бы..Что мы вообще обсуждаем? Чел хочет наследовать xaml — вот ему и объясняй как это. Мне ни надо, у меня нет проблемы с наследованием.

Здравствуйте, Kolesiki, Вы писали:

K>Здравствуйте, karbofos42, Вы писали:

K>>>>Логично сделать окно с общим функционалом, а различающиеся части оформить, например, в виде UserControl и засунуть в окно через всякие ContentPresenter.

K>>>И что в этом логичного?? Ты ООП вообще в глаза видел? Классы там, наследование...

K>>Открой для себя еще агрегацию.

K>Открой для себя "зачем придумывать костыли, когда 40 лет назад уже изобрели ООП".

Неужели Банда Четырёх неправильную книжку написала? Столько архитектурных подходов, и всё про ООП... Но наследование почему-то так странно используют

https://ru.wikipedia.org/wiki/Design_Patterns

Здравствуйте, Kolesiki, Вы писали:


K>JS — это паутинное зло. Без этого дерьма прекрасно работают 99% всех сайтов.

Кинь ссылки хотя бы на 10 сайтов.
JS отличный ЯП если не пытаться писать приложение на двух ЯП одновременно.
Как еще например получить часовой пояс клиента?
Знавал я одного программиста который js отключал, так он сам себе злобный чебурашка

Здравствуйте, Kolesiki, Вы писали:

K>Ребят, интересный вопрос в свете "декларативного ГУЯ" и WPF в частности.

K>Допустим, есть бизнес-задача, где есть ряд однотипных окон (скажем, диалоги и у всех OK/Cancel).
K>Логично было бы, как мастодонты ООП, заделать базовый MyWindow, где есть кнопки OK/Cancel, а однотипные окна унаследовать от этого самого MyWindow и накидать нужные дополнительные редакторы.
Кнопки — можно, но не нужно, как уже сказали ниже. Юзаем контролы и стили, получаем желаемое куда меньшими усилиями.

K>А вот фигушки! 'MyWindow' cannot be the root of a XAML file because it was defined using XAML.
K>Получается, сели мы с этой декларативностью в лужу! Хотя вопрос-то принципиально разрешимый — в том же Delphi можно было спокойно наследовать окна и дополнять контролами.
Просто описывать новое окно надо не только в XAML, но и .CS соответствующий не забыть. Новички часто с этим накалываются.
Но обычно наследовать окна в WPF реально приходится только лишь для каких-то вещей уровня инфраструктуры всего приложения. Всё остальное легче разрулить контролами (потому что окно в WFP — оно тоже контрол)

K>Так или иначе, факт тот, что при всех приятностях декларативности, она проваливается даже на самом базовом принципе ООП.

ООП и декларативность — это лишь инструменты. Равно как и агрегирование.

Здравствуйте, Kolesiki, Вы писали:

K>Ребят, интересный вопрос в свете "декларативного ГУЯ" и WPF в частности.

K>Допустим, есть бизнес-задача, где есть ряд однотипных окон (скажем, диалоги и у всех OK/Cancel).
K>Логично было бы, как мастодонты ООП, заделать базовый MyWindow, где есть кнопки OK/Cancel, а однотипные окна унаследовать от этого самого MyWindow и накидать нужные дополнительные редакторы.

Логично сделать окно с общим функционалом, а различающиеся части оформить, например, в виде UserControl и засунуть в окно через всякие ContentPresenter.

K>А вот фигушки! 'MyWindow' cannot be the root of a XAML file because it was defined using XAML.
K>Получается, сели мы с этой декларативностью в лужу! Хотя вопрос-то принципиально разрешимый — в том же Delphi можно было спокойно наследовать окна и дополнять контролами.

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

K>Может, и в WPF можно заделать какую-никакую наследуемость? Скажем:

K>

K><Window>
K>    <PlaceholderForInheritors />
    
K>    <Button>OK</>
K></>
K>

K>...и тогда VS будет вместо PlaceholderForInheritors давать редактор для внутренних тегов!
K>Понятно, что это костыль и кто-то даже захочет что-то вставить ПОСЛЕ кнопки ОК, но тут уж решать — либо космические архитектуры, либо вполне простое решение 99% проблем.

K>Так или иначе, факт тот, что при всех приятностях декларативности, она проваливается даже на самом базовом принципе ООП.

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

Здравствуйте, Kolesiki, Вы писали:

K>Ребят, интересный вопрос в свете "декларативного ГУЯ" и WPF в частности.

WPF заточен на композицию, там для такого вообще наследоваться не надо

можно к окну диалога добавить attached property "ButtonsTemplate" c типом DataTemplate,
сделать шаблон окна с контентом и панелью снизу, где помещается UI заданный ButtonsTemplate.
шаблон окна поместить в стиль, и все что остается — это применить стиль диалога к окну или контролу и у него автоматом
к контенту добавится панель с кнопками снизу.
99% кейсов покрывается шаблоном по умолчанию с OK/Cancel, но если надо 1 раз вставить другой вид кнопок, делается без
всяких "запихиваний" молотком

Здравствуйте, BlackEric, Вы писали:

BE>Это решается контролами.

Обходные пути я и сам знаю. Вопрос подымается более важный — в принципе построения "декларативных ГУЁв".
Как видно по WPF, если базовое окно сделали на *.cs + *.xaml, унаследоваться и дизайнить уже нельзя. Просто от "окна в *.cs" файле наследоваться можно.

BE>В Делфи для этого использовались фреймы.

Нет. Дельфи прекрасно это делал на "родных окнах".

Здравствуйте, Mr.Delphist, Вы писали:

MD>Кнопки — можно, но не нужно. Юзаем контролы и стили, получаем желаемое куда меньшими усилиями.

Почему ты пытаешься решать свою задачу, вместо той, что я описал? Меня не интересуют чужие идеи с контролами, я их и так знаю.
Я поднял принципиальный вопрос недостатка декларативного гуя — он (в текущем виде) абсолютно неюзабелен в рамках ООП парадигмы. Хотя мы уже лет 30 как строим ООП библиотеки "контролов".

MD>Просто описывать новое окно надо не только в XAML, но и .CS соответствующий не забыть. Новички часто с этим накалываются.

Причём тут это?? Я посто создал тривиальное окно, у него уже есть xaml и cs. А теперь я хочу ещё одно окно — наследника первого и чтобы тоже xaml+cs.

MD>Но обычно наследовать окна в WPF реально приходится только лишь для каких-то вещей уровня инфраструктуры всего приложения.

Я уже описал самый что ни на есть бизнес случай: множество однотипных диалогов.

MD> Всё остальное легче разрулить контролами (потому что окно в WFP — оно тоже контрол)

Никакой логики. Мне пофиг, кто Window в суперклассах, я просто хочу окно, унаследованное от другого окна.

MD>ООП и декларативность — это лишь инструменты. Равно как и агрегирование.

Ну вот я и хочу "всего лишь" использовать ООП на ООП-библиотеке! Для чего тогда все эти развесистые классы в WPF?? Чтобы кнопки кастомайзить?
Дай задачу "однотипных диалогов" — даже школьник тут же придумает "базовый класс-окно"! Это самое прямое и очевидное использование наследования.

Здравствуйте, karbofos42, Вы писали:

K>Здравствуйте, Kolesiki, Вы писали:

K>>Ребят, интересный вопрос в свете "декларативного ГУЯ" и WPF в частности.

K>>Допустим, есть бизнес-задача, где есть ряд однотипных окон (скажем, диалоги и у всех OK/Cancel).
K>>Логично было бы, как мастодонты ООП, заделать базовый MyWindow, где есть кнопки OK/Cancel, а однотипные окна унаследовать от этого самого MyWindow и накидать нужные дополнительные редакторы.

K>Логично сделать окно с общим функционалом, а различающиеся части оформить, например, в виде UserControl и засунуть в окно через всякие ContentPresenter.

И что в этом логичного?? Ты ООП вообще в глаза видел? Классы там, наследование... Самое очевидное решение при описании множества схожих объектов — ОБЩИЙ ПРЕДОК. Точка. А вот теперь, исходя из этой модели, хотелось бы посмотреть, что (не)может "декларативный ГУЙ".


K>Точно можно наследовать окна и кнопочки унаследуются, я так делал и эта дичь работала.

Если базовый класс описан ТОЛЬКО в *.cs файле — да. Но это самый неинтересный случай. Не для того придумывали визуальные инструменты, чтобы заниматься внешним видом в коде!

Итак, возвращаемся к нерешённой проблеме: базовое окно из xaml+cs и окна-наследники из xaml+cs.

Здравствуйте, ksg71, Вы писали:

K>WPF заточен на композицию, там для такого вообще наследоваться не надо

В этом и беда — WPF заточен! Захардкожен киянками по самые гланды. И ленивость вкорячили где надо и не надо, и MVVM у них, одно только забыли — всё это должны использовать люди.

Итак, снова формулирую проблему: есть однотипные окна, у которых напрашивается общий родитель (и не обязательно только с общим ГУЁм — могут быть виртуальные методы).
Как имея базовое окно (xaml+cs) создать наследников, чтобы их тоже можно было дизайнить и писать код?

K>можно к окну диалога добавить attached property

Да можно хоть маршаллинг на Марс организовать! Я прошу решать не ваши личные задачи, а мою — чистый, незамутнённый ООП в ГУЯх.
Можно сформулировать даже жёстче: вот дал вам архитектор структуру: базовое окно, пара виртуальных методов и какие-то общие контролы. И нужны наследники с кастомными дополнениями. Всё это запилить на WPF. Никому не интересно, что можно чесать правое ухо левой рукой, потому что уже дана чёткая иерархия классов, задача прогера — лишь реализовать это при помощи WPF.
Насколько я вижу, WPF тут лажает по полной.

Здравствуйте, Kolesiki, Вы писали:

K>Здравствуйте, karbofos42, Вы писали:

K>>Здравствуйте, Kolesiki, Вы писали:

K>>>Ребят, интересный вопрос в свете "декларативного ГУЯ" и WPF в частности.

K>>>Допустим, есть бизнес-задача, где есть ряд однотипных окон (скажем, диалоги и у всех OK/Cancel).
K>>>Логично было бы, как мастодонты ООП, заделать базовый MyWindow, где есть кнопки OK/Cancel, а однотипные окна унаследовать от этого самого MyWindow и накидать нужные дополнительные редакторы.

K>>Логично сделать окно с общим функционалом, а различающиеся части оформить, например, в виде UserControl и засунуть в окно через всякие ContentPresenter.

K>И что в этом логичного?? Ты ООП вообще в глаза видел? Классы там, наследование...

Открой для себя еще агрегацию.

K>Самое очевидное решение при описании множества схожих объектов — ОБЩИЙ ПРЕДОК. Точка.

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

K>А вот теперь, исходя из этой модели, хотелось бы посмотреть, что (не)может "декларативный ГУЙ".

Зачем самому себе создавать трудности какой-то выдуманной дурацкой моделью?
Можно конечно суп вилкой есть, но зачем?

K>>Точно можно наследовать окна и кнопочки унаследуются, я так делал и эта дичь работала.

K>Если базовый класс описан ТОЛЬКО в *.cs файле — да. Но это самый неинтересный случай. Не для того придумывали визуальные инструменты, чтобы заниматься внешним видом в коде!

K>Итак, возвращаемся к нерешённой проблеме: базовое окно из xaml+cs и окна-наследники из xaml+cs.

Нет. Делал базовое окно в xaml+cs и наследники так же. Дичь, но работало.
UPD. Сейчас подумал, возможно там был UserControl, а не Window, но точно с наследованием было и я не понимаю зачем нужно именно наследование, да еще и в интерфейсе.

Здравствуйте, Kolesiki, Вы писали:

K>Здравствуйте, ksg71, Вы писали:

K>>WPF заточен на композицию, там для такого вообще наследоваться не надо

K>В этом и беда — WPF заточен! Захардкожен киянками по самые гланды. И ленивость вкорячили где надо и не надо, и MVVM у них, одно только забыли — всё это должны использовать люди.

K>Итак, снова формулирую проблему: есть однотипные окна, у которых напрашивается общий родитель (и не обязательно только с общим ГУЁм — могут быть виртуальные методы).
K>Как имея базовое окно (xaml+cs) создать наследников, чтобы их тоже можно было дизайнить и писать код?

K>>можно к окну диалога добавить attached property

K>Да можно хоть маршаллинг на Марс организовать! Я прошу решать не ваши личные задачи, а мою — чистый, незамутнённый ООП в ГУЯх.
K>Можно сформулировать даже жёстче: вот дал вам архитектор структуру: базовое окно, пара виртуальных методов и какие-то общие контролы. И нужны наследники с кастомными дополнениями. Всё это запилить на WPF. Никому не интересно, что можно чесать правое ухо левой рукой, потому что уже дана чёткая иерархия классов, задача прогера — лишь реализовать это при помощи WPF.
K>Насколько я вижу, WPF тут лажает по полной.

задача прогера, сделать UI, быстро, с минимумом телодвижений, расширяемо и т.д.
WPF вполне себе годен для этого, но действительно не вяжется с "незамутнённым ООП в ГУЯх"

Здравствуйте, karbofos42, Вы писали:

K>>>Логично сделать окно с общим функционалом, а различающиеся части оформить, например, в виде UserControl и засунуть в окно через всякие ContentPresenter.

K>>И что в этом логичного?? Ты ООП вообще в глаза видел? Классы там, наследование...

K>Открой для себя еще агрегацию.

Открой для себя "зачем придумывать костыли, когда 40 лет назад уже изобрели ООП".

K>>Самое очевидное решение при описании множества схожих объектов — ОБЩИЙ ПРЕДОК. Точка.

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

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

K>>А вот теперь, исходя из этой модели, хотелось бы посмотреть, что (не)может "декларативный ГУЙ".

K>Зачем самому себе создавать трудности какой-то выдуманной дурацкой моделью?
K>Можно конечно суп вилкой есть, но зачем?

Выдуманной... но не мной, а "изобретателями ООП". Кто ты такой, чтобы с ними спорить??

K>>Итак, возвращаемся к нерешённой проблеме: базовое окно из xaml+cs и окна-наследники из xaml+cs.

K>UPD. Сейчас подумал, возможно там был UserControl, а не Window

Вот именно. Внимательно читаем проблему, вникаем, отвечаем.

K>... и я не понимаю зачем нужно именно наследование, да еще и в интерфейсе.

Ну так почитай Буча что ли... он всё разжёвывает, кто такой предок и зачем он нужен! Я это тоже разжевал.
Хочешь писать стотыщ однотипных методов — ради бога, я напишу один и просто унаследуюсь.

Здравствуйте, barn_czn, Вы писали:

_>Ты путаешь наследование в коде и разметку. Разметка в принципе не наследуется.

Это в твоём ограниченном воображении. Подыми глаза и посмотри, что я написал в стартовом сообщении.

Здравствуйте, barn_czn, Вы писали:

_>Ну давай еще разжуем. Представь 3 окна. По части фукнционала (т.е. в коде) все одинаково.

нет. В коде тоже будут различия — переопределённые методы, свои методы.

_> Но внешний вид разный. И что твой ООП должен делать, что наследовать?

Всё — внешний вид и поведение.

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

Белиберда полная — учись выражать мысли. Просто посмотри, что я предложил в топике — там пусть и убогонькое, но наследование UI — собсно, его за глаза достаточно.

Здравствуйте, Mr.Delphist, Вы писали:

MD>Просто описывать новое окно надо не только в XAML, но и .CS соответствующий не забыть. Новички часто с этим накалываются.

Могу ошибиться, но кажись там тогда наследника в дизайнере не получится редактировать?

Здравствуйте, barn_czn, Вы писали:

В разметке что?
xaml(xml), который как известно не является ООП-языком.
Поэтому и придумали "удобные" генераторы списков в функциональных языках и отделили описание
интерфейса от стиля. И если язык поддерживает горячую перезагрузку кода, то дизайнер вообще не нужен становится, прекрасный пример того, что это возможно .
Жалко, что avalonia ui не поддерживается.

Здравствуйте, barn_czn, Вы писали:

K>>Насколько я вижу, WPF тут лажает по полной.

_>Насколько я вижу у топикстартера ООП мозга. Он в принципе не понимает как это так что ООП молотком ни все забивается
_>Ну давай еще разжуем. Представь 3 окна. По части фукнционала (т.е. в коде) все одинаково. Но внешний вид разный. И что твой ООП должен делать, что наследовать?

Не совсем, xaml — это описание части кода класса окна. При изменении в дизайнере идет фоновая генерация partial файлов. У вашего окна появляются дополнительные аттрибуты и т.п. в рантайме по ним генерится UI.
Если бы это был не xaml, а обычный код вы легко бы могли внести в наследнике изменения в дерево компонентов окна. То что вы назвали внешним видом, это лишь часть поведения класса отвечающие за отрисовку на экране окошка и реакции на события(клики, нажатия клавиш — рекация на действия пользователя или внутренние события программы).

Здравствуйте, Kolesiki, Вы писали:

K>Ребят, интересный вопрос в свете "декларативного ГУЯ" и WPF в частности.

K>

K><Window>
K>    <PlaceholderForInheritors />
    
K>    <Button>OK</>
K></>
K>

Мое предположение, что просто не захотели в мс возиться с наследованием, т.к. по сути описание xaml перегоняется в код при компиляции или же нет(код генерится в рантайме при каждом запуске wpf)?

Где времена GWT и ajax когда json генерился с помощью out.println?

Кстати, тут статейка была на хабре 2017 года, что через год-два дотнет потеснит жаву на рынке веба. И чего?

Кинулся, а аналогов GWT нет близко. Пытался завести Blazor Server, но у него с жизненным циклом какая-то фигня — следит только за простыми пропертями, если нужно две сущности отредактировать на странице, то состояние сбрасывается, при этом интеграция с MVC частичная(например, нет доступа к http-context).

Здравствуйте, barn_czn, Вы писали:


AA>>Если бы это был не xaml, а обычный код

_>Если бы да ка бы..Что мы вообще обсуждаем? Чел хочет наследовать xaml — вот ему и объясняй как это. Мне ни надо, у меня нет проблемы с наследованием.
OK!

Здравствуйте, Mr.Delphist, Вы писали:

MD>Здравствуйте, Kolesiki, Вы писали:

K>>Здравствуйте, karbofos42, Вы писали:

K>>>>>Логично сделать окно с общим функционалом, а различающиеся части оформить, например, в виде UserControl и засунуть в окно через всякие ContentPresenter.

K>>>>И что в этом логичного?? Ты ООП вообще в глаза видел? Классы там, наследование...

K>>>Открой для себя еще агрегацию.

K>>Открой для себя "зачем придумывать костыли, когда 40 лет назад уже изобрели ООП".

MD>Неужели Банда Четырёх неправильную книжку написала? Столько архитектурных подходов, и всё про ООП... Но наследование почему-то так странно используют

MD>https://ru.wikipedia.org/wiki/Design_Patterns


Банда, банда.... КАК унаследовать WPF-ное окно? Ответ будет?

Здравствуйте, barn_czn, Вы писали:


K>>Короче, судя по ответам, я был прав

_>Ты прав, иди с миром. Ни дай бог с тобой на проекте быть.

Переход на личности, после того, как обосрался по всем аргументам — всё понятно с тобой, твоя трепологическая "помощь" точно не нужна.

Здравствуйте, Kolesiki, Вы писали:

K>Банда, банда.... КАК унаследовать WPF-ное окно? Ответ будет?

Так давали уже где-то в параллельной ветке ответ: всё наследуется, если мухи отдельно и котлеты отдельно.
1) Создаём нужную иерархию окон в CS-файлах для описания бизнес-логики

class SuperDuperWin : Window {...}
class ParaTruperWin : SuperDuperWin {...}

2) создаём нужные стили в XAML для описания внешнего вида (которые можно применить на target-класс или любой наследник)

<Style x:Key="SuperDuperStyle" TargetType="SuperDuperWin">...</Style>

3) агрегируем бизнес-логику и внешний вид:

<ParaTruperWin x:Class="oh_shi_HereWeGoAgain" Style="SuperDuperStyle">
...

...
Профит!

А если хочется "вот такое же окно но с кнопками Yes/No/Cancel вместо Yes/No в стиле наследования Delphi DFM, то ничего не поделаешь — такого в WPF действительно нет. Потому что вместо молотка и отвёртки здесь есть полный комплект инструментов. Надо лишь начать ими пользоваться.

Здравствуйте, Mr.Delphist, Вы писали:

MD>Так давали уже где-то в параллельной ветке ответ: всё наследуется, если мухи отдельно и котлеты отдельно.

Спасибо за ответ, но это именно то, что я знал и сразу оговорил как непримелемое решение. Вся эта городильня с промежуточными окнами мне нафиг не нужна. Мы программируем в 21 веке, космические архитекторы со всеми своими MVC обосрались ещё в 20-ом. Правильная тенденция — упрощение разработки и архитектуры, т.к. сложность систем повысилась на порядок. Отсюда, больше нет места "костылям" и "обходным путям". Если задача не решается очевидным способом, то это говно, а не инструменты (пусть даже их больше, чем молоток и отвёртка). Это и я пытался выяснить: можно ли решать задачу напрямую. Сходу я решить не смог, но теплилась надежда, что просто не знаю какой-то хитрожопой тонкости от бравых архитекторов WPF. Оказалось, никаких секретов нет — WPF действительно неуклюжее УГ. Вся его доблесть — на уровне хелловорлдов и "поместить иконку на кнопку", мало-мальски сложные вещи сразу вылезают чуть ли не в переопределение контрола(!). Чисто поржать, вот вам элементарная задача "выровнять заголовок GroupBox", первый же ответ:

It's simple! Just edit Template of GroupBox

Извините, если я по ТАКОЙ херне буду редактировать шаблоны, то идите-ка вы в шреддер со своим WPF! Ну и со своим наследованием форм, конечно же.

Это всё не к вам, конечно же. Моё почтение тем, кто отважно борется с индусячими архитекторами WPF

Здравствуйте, varenikAA, Вы писали:

AA>Мое предположение, что просто не захотели в мс возиться с наследованием

Вот так просто? "Мы это не умеем, поэтому мы это не будем" — так что ли? Охренеть! 40 лет развития ООП коту под хвост.

AA>, т.к. по сути описание xaml перегоняется в код при компиляции или же нет(код генерится в рантайме при каждом запуске wpf)?

См. файлы *.g.cs в obj/

AA>Кстати, тут статейка была на хабре 2017 года, что через год-два дотнет потеснит жаву на рынке веба. И чего?

И ничего Кто умел в C#, тот спокойно продолжает делать ASP. Сосчитать их невозможно, т.к. невозможно получить от страницы ответ "кто тебя сгенерил".

AA>Кинулся, а аналогов GWT нет близко

Зачем тебе это говно? Веб не должен превращаться в филиал психушки с JS головного мозга. Если ты выводишь UI в веб, ты обязан охватывать максимальную аудиторию, а значит ограничить свои фантазии на уровне HTML 3 и без скриптов. Для мобильного применения этого хватает на 200%. Суть веба в том и состоит, что помимо rich desktop есть возможность ограниченно работать через браузер. Который, как правило, будет запускаться на каком-нть смарт-фуфле с 5-6" экрана. Вот для таких "веб-приложения" и придумали. Но потом что-то пошло не так и вместо того, чтобы писать простые ASP, ты бегаешь и ругаешь razor (который тебе нафиг не обздался).

Здравствуйте, Kolesiki, Вы писали:

K>Зачем тебе это говно?
За год многое изменилось. blazor уже продакт реди (в 6-й корке).
легко стыкуется с razor templates.
плюсы: генерится на сервере. фулконтакт через сигнал-Р.
не нужно хранить стэйт в странице.
приятно разбивать страницу на компоненты.

Здравствуйте, vaa, Вы писали:

vaa>плюсы: генерится на сервере. фулконтакт через сигнал-Р.
vaa>не нужно хранить стэйт в странице.
vaa>приятно разбивать страницу на компоненты.

А он умеет генерировать HTML без JS? Чтобы в Опере 9 работало. Или того смешнее — у немалой части людей, где ещё даже XP стоит (и эксплорер 9).

Меня что пугает во всей это "автогенерации" — ты теряешь контроль. Вчера ты мог чёрта лысого на страницу вывести, а сегодня виновато пожимаешь плечами "ну, это всё он сгенерил!". Если ты не контролируешь решение, значит контролируют тебя.

Здравствуйте, Kolesiki, Вы писали:


K>А он умеет генерировать HTML без JS? Чтобы в Опере 9 работало. Или того смешнее — у немалой части людей, где ещё даже XP стоит (и эксплорер 9).
RenderMode

ПОЛЯ
Server 2
Отображает маркер для серверного приложения Блазор. Это не относится к выходным данным компонента. При запуске агента пользователя он использует этот маркер для начальной загрузки приложения блазор.

ServerPrerendered 3
Преобразует компонент в статический HTML и включает маркер для серверного приложения Блазор. При запуске агента пользователя он использует этот маркер для начальной загрузки приложения блазор.

Static 1
Преобразует компонент в статический HTML.

K>Меня что пугает во всей это "автогенерации" — ты теряешь контроль. Вчера ты мог чёрта лысого на страницу вывести, а сегодня виновато пожимаешь плечами "ну, это всё он сгенерил!". Если ты не контролируешь решение, значит контролируют тебя.
на самом деле blazor это генератор html, можно вывести что угодно. просто наконец избавились от необходимости писать всю логику на json+js что конечно удобно если есть выделенный фронтэндер или
херачить все на stateless запрос-ответ. блазор во втором случае избавляет от необоходимости гонять стэйт в запросе, это в свою очередь ускоряет разработку и избавляет от несоглассованности клиента и сервера еще на этапе компиляции.
Если же любите xaml можно посмотреть в сторону uno. не смотрел правда работает ли уно в сервер-моде.

PS Если софт будет полезный/интересный клиент поставить себе виднос 11. стопудов.

Здравствуйте, vaa, Вы писали:

K>>А он умеет генерировать HTML без JS?
vaa>RenderMode
vaa>Преобразует компонент в статический HTML

Не увидел ответа. Статический HTML — и что? Про JS ни слова.


K>>Меня что пугает во всей это "автогенерации" — ты теряешь контроль. Вчера ты мог чёрта лысого на страницу вывести, а сегодня виновато пожимаешь плечами "ну, это всё он сгенерил!". Если ты не контролируешь решение, значит контролируют тебя.
vaa>на самом деле blazor это генератор html, можно вывести что угодно

Я в blazor глубоко не влезал, но если ты 100% контролируешь HTML — хорошо.

vaa>PS Если софт будет полезный/интересный клиент поставить себе виднос 11. стопудов.

Это ты к чему?

Здравствуйте, Kolesiki, Вы писали:

K>>>А он умеет генерировать HTML без JS?

Это и есть ответ => K> Про JS ни слова.
нет его. только html. IE11 поддерживается. насчет оперы уточнять надо.
K>Это ты к чему?
про клиентов с хрюшкой и оперой 9-й. что за олды?

Здравствуйте, vaa, Вы писали:

vaa>Здравствуйте, Kolesiki, Вы писали:

K>>>>А он умеет генерировать HTML без JS?

vaa>Это и есть ответ => K> Про JS ни слова.
vaa>нет его. только html.

Наивный чебурашка.... Если MS что-то не говорит, это не значит, что этого нет. Сейчас буквально чуть глубже влез в тему — там без JS ВООБЩЕ НИЧЕГО работать не будет!


K>>Это ты к чему?
vaa>про клиентов с хрюшкой и оперой 9-й. что за олды?

Ну какие это олды? Это корпоративный сектор, где НИ КОПЕЙКИ не потратят без весомого обоснования. Есть техника, на ней работает система. С какого перепоя компания должна выкидывать абсолютно рабочий комплекс и ставить новую перекрашенную хрень от MS? (есессно, с покупкой нового железа и лицензий)

JS — это паутинное зло. Без этого дерьма прекрасно работают 99% всех сайтов. Но уже нет — головотяпы и вчерашние ПТУшники набежали в ИТ и засрали его своими скриптами. Доходило до идиотии, когда на обычный <span> вешался клик, чтобы.... ОТКРЫТЬ ССЫЛКУ! Дебилам что, слишком краткий тег <a> не понравился?? И так на целой куче сайтов — ни строчки не прочитать, пока этот говноскрипт не подгрузит их бесценный контент.

Короче, после часового копания темы я понял, что blazor — очередное наколенное поделие MS с нулевыми перспективами. Всякое говнецо типа "увеличить счётчик по клику" — работает, но в нормальном вебе ему делать нечего.

Здравствуйте, Kolesiki, Вы писали:

K>Наивный чебурашка.... Если MS что-то не говорит, это не значит, что этого нет. Сейчас буквально чуть глубже влез в тему — там без JS ВООБЩЕ НИЧЕГО работать не будет!
вы будете страдать из — за того что у вас не работает блэйзор?


K>Ну какие это олды? Это корпоративный сектор, где НИ КОПЕЙКИ не потратят без весомого обоснования. Есть техника, на ней работает система. С какого перепоя компания должна выкидывать абсолютно рабочий комплекс и ставить новую перекрашенную хрень от MS? (есессно, с покупкой нового железа и лицензий)
Прямо сталинский подход! IT-директора как правило умеют убеждать руководство. У нас с 85 года курс на модернизацию, однако.
Даже на нищей почте роисси регулярно ПК обновляют по производимый софт. такова реальность. А там ритэйл написали на MS Dynamics + Devexpress. Напомню, это АО, где "деньги считать умеют".


K>Короче, после часового копания темы я понял, что blazor — очередное наколенное поделие MS с нулевыми перспективами. Всякое говнецо типа "увеличить счётчик по клику" — работает, но в нормальном вебе ему делать нечего.
простыми словами: блайзор это реактр на C# — т.е. общая кодовая база, проверка типов, навигация по коду. это фуллстэйт без необходимости мапить айдищники на контроллы в случае голого mvc или колбасить связку json + js + server для сохранения консистентности данных.
Это в свою очередь повышает качество кода и скорость разработки.
Прогресс? нет, не слышали

Здравствуйте, Osaka, Вы писали:

K>>либо космические архитектуры, либо вполне простое решение 99% проблем.
O>В старину недолго существовало такое интересное явление, как Delphi8 и VCL.Net — там сделали возможность в VCL'ной форме (dfm), с её полностью работоспособным визуальным наследованием, использовать в контролах нетовские источники данных (DataTable и т. п.) Но, увы, "спектакль прошёл успешно, а вот публика провалилась".

А что сейчас у Delphi в плане поддержки .NET ?

Есть ли компилятор и IDE, одновременно поддерживающие Object Pascal, .NET и FMX (FireMonkey) хотя бы для Windows?

Что из этого умеет https://docs.elementscompiler.com/Oxygene/
? Только Object Pascal for .NET без FMX?

В идеале бы конечно кроссплатформенный FMX с автоматизацией из .NET программ, в т.ч. из C# и VB.NET

Вроде бы есть какой-то FMX для Linux?

https://www.fmxlinux.com/

Но что там с поддержкой .NET ? Как прикрутить такой Linux FMX к программе .NET on Linux кроме использования всевозможных RPC, IPC, etc. ?

Кстати, DevExpress почему-то не стал развивать свой FMX набор?

https://community.devexpress.com/blogs/ctodx/archive/2020/12/02/fmx-grid-future-plans.aspx

Зато появились новые таланты:

https://www.steema.com/product/gridvcl#features

K>Итак, снова формулирую проблему: есть однотипные окна, у которых напрашивается общий родитель (и не обязательно только с общим ГУЁм — могут быть виртуальные методы).
K>Как имея базовое окно (xaml+cs) создать наследников, чтобы их тоже можно было дизайнить и писать код?

Сделать свой User контрол, который описывает островок однотипности, поместить его программно в наследуемое окно без декларативности и потом наследовать это окно?

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

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

В крайнем случае все визуально декларативное размещать в кастом контролах и добавлять их программно в наследуемую иерархию классов в runtime?

Здравствуйте, Kolesiki, Вы писали:

K>Ну с такой логикой вам в мир BASIC, а у нас в ООП наследование и выделение общего предка как бы базовая вещь.

В VB.net с наследованием как раз все прекрасно в отличии от супер современных ЯП, где в лучшем случае от силы есть так называемые трейты иногда с необходимостью набора много буков, собственно от чего классический ОПП нас раньше избавлял автоматически.

K>Выдуманной... но не мной, а "изобретателями ООП". Кто ты такой, чтобы с ними спорить??

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

Здравствуйте, Ikemefula, Вы писали:

>Например, в каком то наследнике придется убрать Ok или Cancel и оставить всё остальное. Упс.

Например, в около базовом классе сделать свойство, определяющее такие нюансы поведения?

K> Извините, если я по ТАКОЙ херне буду редактировать шаблоны, то идите-ка вы в шреддер со своим WPF! Ну и со своим наследованием форм, конечно же.

Любопытно, но DevExpress тоже когда-то решили не использовать WPF для XAF.

Здравствуйте, Kolesiki, Вы писали:

K>JS — это паутинное зло. Без этого дерьма прекрасно работают 99% всех сайтов. Но уже нет — головотяпы и вчерашние ПТУшники набежали в ИТ и засрали его своими скриптами. Доходило до идиотии, когда на обычный <span> вешался клик, чтобы.... ОТКРЫТЬ ССЫЛКУ! Дебилам что, слишком краткий тег <a> не понравился?? И так на целой куче сайтов — ни строчки не прочитать, пока этот говноскрипт не подгрузит их бесценный контент.

Полюбуйся:

https://www.linux.org.ru/forum/talks/16883062?cid=16886809

Здравствуйте, vaa, Вы писали:

> Даже на нищей почте роисси регулярно ПК обновляют по производимый софт.

А можно было использовать Thin clients ?

Здравствуйте, sanyock, Вы писали:

S>Здравствуйте, vaa, Вы писали:

>> Даже на нищей почте роисси регулярно ПК обновляют по производимый софт.

S>А можно было использовать Thin clients ?

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

Здравствуйте, sanyock, Вы писали:

>>Например, в каком то наследнике придется убрать Ok или Cancel и оставить всё остальное. Упс.

S>Например, в около базовом классе сделать свойство, определяющее такие нюансы поведения?

Не нужно такого свойства. Нам нужна композиция примерно такая: панель + редактор + ok+cancel. Все однотипные формы должны иметь именно такую структуру. Если понадобится не ok cancel, то мы просто подменяем кнопки, например, try+ok-cancel, или, например, заменяем кнопки на кнопка-список.
вводить какой то базовый класс типа формы нужно тогда, когда понадобится какой то единообразный подход, апи ко всем похожим формам. В этом случае добавляем модал, который состоит из: панель, редактор, кнопки.

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