Вопрос

У нас есть приложение, которое должно быть гибким в том, как оно отображает свою основную форму пользователю - в зависимости от пользователя форма должна немного отличаться, возможно, дополнительная кнопка здесь или там, или какой-то другой нюанс.Чтобы прекратить писать код для явного удаления или добавления элементов управления и т.д., Я обратился к визуальному наследованию, чтобы решить проблему - в том, что я считал аккуратным, чистым и логичным стилем OO - оказывается, что в половине случаев унаследованным формам трудно отображать темы в VS без уважительной причины и т.д. - и у меня такое ощущение, что разработчики и в некоторой степени Microsoft избегают практики визуального наследования - вы можете подтвердить это, я здесь что-то упускаю?

С уважением.

Это было полезно?

Решение

Я думал, что они более или менее разобрались с проблемами дизайнера настольных компьютеров в 2005 году.Вы пробовали использовать обычных преступников?

  • Никаких абстрактных типов элементов управления
  • Нет аргументов конструктора ни в какой форме
  • Инициализация перенесена в Form_Load в отличие от Ctor
  • Нет элементов управления в том же проекте, что и usercontrol / form, в который они помещены
  • Закройте все документы -> Очистить -> Перестроить
  • Перезапуск VS

Мне казалось, что до тех пор, пока вы выполняете все вышеперечисленное, это работает.....в основном.

Другие советы

Я изучаю (по общему признанию, скоро устаревший) MCAD, и частью элемента WinForms было визуальное наследование.

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

Для меня, основной проблемой всегда является инициализация..Вам нужно помнить, что дизайнер не может / не создает экземпляры форм таким же образом, как это делается во время выполнения (аналогично, он не может этого сделать с веб-разработчиком, поэтому при рендеринге пользовательского элемента управления требуется осторожность).

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

Лично я не видел никаких свидетельств того, что его "избегали". AFAIK, по-прежнему хорошей практикой является повторное использование кода там, где это возможно.Визуальное наследование обеспечивает это.

Могу ли я предложить создать новый вопрос с фактический у вас возникли проблемы с образцом кода?Затем мы можем посмотреть на это, чтобы понять, сможем ли мы заставить это работать, и объяснить почему :)

Я видел некоторые проблемы в VS2005 с этим.В основном они были вызваны проблемами с построением форм-объектов в конструкторе.Были проблемы с кодом, который пытался получить доступ к базе данных из конструкторов форм и т.д.

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

Другой проблемой, которую я могу вспомнить, были дженерики в классах форм

public class MyForm<MyObject> : Form

это не сработает

Я часто натыкаюсь на подобные проблемы в Visual Studio.Во многих случаях MSVS forms designer не может правильно отобразить форму.В те дни, когда я работал с WinForms, мне приходилось проделывать всевозможные странные трюки, чтобы включить некоторые сложные сценарии.Однако я думаю, что использование визуального наследования очень полезно и не должно быть выброшено, независимо от ошибок MSVS designer.

Я думаю, что нашел способ избежать этой проблемы.

Не подключайте событие Form_Load к вашей родительской форме, это нарушит работу дизайнера.

Также не удаляйте пустой конструктор по умолчанию из Visual Studio в Родительской форме.Если вы хотите внедрить зависимость, создайте другой конструктор.

Вот так:

public ProductDetail()
{
    InitializeComponent();
}

public ProductDetail(ISupplierController supplierController) : base()
{
    InitializeComponent();
    this.supplierController = supplierController;
}

Затем вы все равно можете сделать это из своей унаследованной формы:

public NewProduct(ISupplierController supplierController)
    : base(supplierController)
{
    InitializeComponent();
}

До сих пор у меня это работало, и у меня тоже были некоторые странные проблемы с дизайнером.

твое здоровье, Дэниел

Читать это: http://cs.rthand.com/blogs/blog_with_righthand/archive/2005/11/10/186.aspx

AFAIK, все еще существуют проблемы с визуальным наследованием и объектами, которые полагаются на коллекции для элементов дизайна, обычно элементов управления сеткой и т.д.Я полагаю, что MS все еще удалила возможность изменения f.ex.просмотр сетки в унаследованной форме / usercontrol и т.д.Но другие элементы управления, такие как TextBox, Form, UserControl, Panel и т.д.должно сработать так, как ожидалось.

До сих пор у меня не было проблем с тем, что VI сам использует сторонние элементы управления grid, но вы должны быть осторожны, в частности, следует избегать удаления элементов из коллекций.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top