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

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

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

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

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

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

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

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

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

Здравствуйте, 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 — собсно, его за глаза достаточно.

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

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

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

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

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

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

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

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

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.

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

Здравствуйте, 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!

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

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

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

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

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

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

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

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

Здравствуйте, 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. стопудов.