Visual Studio нарушает визуальное наследование

Я создал FormBase, от которого унаследовал FomBaseList и FormBaseDetail.
Все остальные формы в проекте унаследованы от FormBaseList или FormBaseDetail.
Теперь кажется, что у VS есть огромные проблемы с этим, и моя самая большая проблема заключается в том, что VS продолжает записывать значения свойств из формы Ancestor в Designer.cs из дочерней формы.

например, в FormBaseList у меня есть это свойство / значение:

this.gttDXGridView1.OptionsView.ShowAutoFilterRow = true;

Я ожидаю, что в производной форме, например FormClientList, это значение не упоминается в файле designer.cs, потому что он должен получать значение от своего родителя. Другими словами, просто простое простое ООП.
И я также ожидаю, что когда я изменю свойство в FormClientList на

this.gttDXGridView1.OptionsView.ShowAutoFilterRow = false;

что это рассматривается как переопределение базового класса.
Однако VS продолжает перезаписывать свойство в FormClientList.Designer.cs значением, найденным в FormBaseList.Designer.cs.
Это нарушает правила ООП, на мой взгляд, другие инструменты, поддерживающие визуальное наследование, например Например, Delphi делает это правильно.

Как я могу запретить VS делать это?
Свойства изменяются с помощью конструктора.
Все элементы управления являются элементами управления DevExpress или производными от элемента управления DevExpress.

Другой пример, который работает как раз наоборот, так что это очень странно.

Например, поместите кнопку в BaseForm и дайте ей изображение.
Кнопка с изображением появляется во всех производных формах.
Теперь измените изображение на кнопке BaseForm.
Вы ожидаете, что изображение можно также изменить во всех производных формах, но этого не происходит.
Я обнаружил, что VS снова записал значение свойства кнопки во все производные файлы designer.cs, и на этот раз он не перезаписывает их.


person GuidoG    schedule 21.11.2018    source источник
comment
В VS нет встроенного механизма для этого. DevExpress - это тот поставщик элементов управления, который, вероятно, включит собственный сериализатор кода в свой конструктор элементов управления. Вы должны спросить их.   -  person Hans Passant    schedule 21.11.2018
comment
@HansPassant Хорошо, я буду, по крайней мере, я уже знаю это, теперь это сужает мой поиск   -  person GuidoG    schedule 21.11.2018
comment
Ваш Другой пример → Я не могу это подтвердить. Если у вас есть кнопка с изображением в базовой форме, если вы измените изображение кнопки в базовой форме и перестроите проект, кнопка в производной форме отобразит новое изображение. (Если вы не изменили изображение кнопки в производной форме.)   -  person Reza Aghaei    schedule 21.11.2018
comment
Во-первых, визуальное наследование на Winforms не очень дружелюбно, если вы можете этого избежать, просто избегайте этого. Я знаю, что когда-то это выглядит отличной идеей на бумаге, но ... Мой единственный совет, чтобы избежать большей части проблемы, - убедиться, что все дочерние формы закрыты при редактировании / обновлении базовой формы и построить проект после любых изменений базовой формы перед повторным открытием ребенка. Надеюсь, это поможет тебе.   -  person Marco Guignard    schedule 21.11.2018
comment
@RezaAghaei Ну, VS записал значение свойства для изображения во всех производных файлах Desinger.cs, так что я думаю, это считается изменением его в производных формах. Проблема в том, что VS не должен был этого делать.   -  person GuidoG    schedule 21.11.2018
comment
@MarcoGuignard Да, я на собственном опыте убедился, что VS не является другом Visual Inheritance. Я привык работать в Delphi, где это работает очень хорошо, поэтому я просто применил ту же идею к winforms ...   -  person GuidoG    schedule 21.11.2018
comment
@GuidoG Не годится. В производной форме он сериализует только что измененные свойства. Организуйте действительно простой тест без каких-либо сторонних элементов управления в новом проекте, чтобы увидеть его поведение. Убедитесь, что после каждого изменения базовой формы вы строите проект. Без действительно простого и понятного теста у вас могут быть неточные / неправильные наблюдения, которые приведут вас в неверном направлении.   -  person Reza Aghaei    schedule 21.11.2018
comment
@RezaAghaei Ну, HansPassant уже указал на это, и он думает, что DevExpress может быть ответственным здесь, а не VS. Я не сказал этого в своем предыдущем комментарии, извините за это   -  person GuidoG    schedule 21.11.2018
comment
@HansPassant Кажется, вы правы, см. Мой ответ   -  person GuidoG    schedule 22.11.2018


Ответы (1)