О проблеме редактирования наследованных контролов VS2005 - .NET GUI

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

Моя типовая ситуация – необходимость редактировать свойства колонок в гридах (DataGridView). Выходим из положения следующим образом:

1. Добавляем в сборку новый элемент управления, например MyDataGridView
2. Меняем родителя класса на DataGridView
3. Перед стандартным объявлением класса добавляем следующий атрибут:

[Designer("System.Windows.Forms.Design.ControlDesigner, System.Design")]

Также имеются классы для редактирования других типов контролов.
4. Кладем экземпляр MyDataGridView на форму-родителя FormParent, меняем свойство Modifier на Protected
5. Наследуем FormParent, в потомке редактируем MyDataGridView1, наслаждаемся

Сходная проблема ожидает коллег при наследовании toolstrip’ов. Применяется аналогичное решение.

using System;
..
using System.Windows.Forms;

namespace MyClientLogic
{

    [Designer("System.Windows.Forms.Design.ControlDesigner, System.Design")]
    public partial class ctrlSlyGrid : System.Windows.Forms.DataGridView
    {
        public ctrlSlyGrid()
        {
            InitializeComponent();
        }
    }
}

ps сорри за возможный баян.

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

_>В настоящее время проблема редактирования (вернее, отсутствия оного) наследованых элементов управления декларируется MS, как баг, надлежащий исправлению в следующих версиях.
Баян только в том, что это не баг а AS DESIGNED (к большоум ужасу многих) и fixed оно, я так понял, никада не будет. А так все верно, теперь каждый будет извращаться с контролами, у которых есть свойство-коллекция, чтобы добиться от них любви в visual inheritance.

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

H>Баян только в том, что это не баг а AS DESIGNED (к большоум ужасу многих) и fixed оно, я так понял, никада не будет. А так все верно, теперь каждый будет извращаться с контролами, у которых есть свойство-коллекция, чтобы добиться от них любви в visual inheritance.
не хочу быть голословным, на сайте ms это объявлено as bug. за что купил, за то и продаю.

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

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

H>>Баян только в том, что это не баг а AS DESIGNED (к большоум ужасу многих) и fixed оно, я так понял, никада не будет. А так все верно, теперь каждый будет извращаться с контролами, у которых есть свойство-коллекция, чтобы добиться от них любви в visual inheritance.
_>не хочу быть голословным, на сайте ms это объявлено as bug. за что купил, за то и продаю.
Можно ссылку. Почитайте еще здесь.
ЗЫ:Лично мне все равно, баг это или нет, просто обЫдно, что такие нужные вещи не реализованы

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

H>Здравствуйте, ice_croft, Вы писали:
H>Можно ссылку. Почитайте еще здесь.
H>ЗЫ:Лично мне все равно, баг это или нет, просто обЫдно, что такие нужные вещи не реализованы :(

да, здесь и читал. оттуда пошёл на
http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=02f9cd99-08a7-4efa-92d0-99a53b91d302

но, в соседней ветке коллеги говорят о похаканной сборке system.design. может есть эта длл у кого?

_>Сходная проблема ожидает коллег при наследовании toolstrip’ов. Применяется аналогичное решение.

Попробовал пррименить для MenuStrip

using System;
..
using System.Windows.Forms;
namespace MyClientLogic
{
    [Designer("System.Windows.Forms.Design.ControlDesigner, System.Design")]
    public partial class MyMenuStrip : MenuStrip
    {
        public MyMenuStrip()
        {
            InitializeComponent();
        }
    }
}

В форме потомке дизайнере действительно позволил редактировать все поля MenuStrip (точнее позволил в окне Properties, в самом дизайнере меню по прежнему недоступно). НО наиболее актуальное свойство Items имеет значение ReadOnly, вместо привычной кнопки добавления элементов.
Что сделано не так и что надо сделать делать ? Ессно, набивать код добавления элементов руками не считается

Скорее это заявлено(!) как баг тестерами.

Насколько я слышал — МС зарыло рога метров на 10 в землю в этом вопросе и пустило корни. Да и правильно это, на самом деле. Нефиг ерундой заниматься.

Да и вообще, есть всего одна правильная точка зрения — точка зрения какого-нить менеджера МС. Или вы еще не заметили этого?

—

Real programmers don't comment their code. If it was hard to write, it should be hard to understand.

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

>>Да и вообще, есть всего одна правильная точка зрения — точка зрения какого-нить менеджера МС. Или вы еще не заметили этого?

Еще более правильная точка зрения — это точка зрения твоего PM, который чихал на всех менеджеров Microsoft вместе взятых

[[url=http://www.gotdotnet.ru/DotNet/FAQ/OfflineFAQ/236958.aspx]Offline FAQ[/url]] [1.01]
2 min @ 56.6 kbps

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

>>Еще более правильная точка зрения — это точка зрения твоего PM, который чихал на всех менеджеров Microsoft вместе взятых

Не-е.... Это ВТОРАЯ ПРАВИЛЬНАЯ точка зрения.

Из практики — когда имеешь две ПРАВИЛЬНЫХ точки зрения, это значит, что настоящая правильная точка зрения сидит где-то в курилке и в споре участия не принимала.

—

Real programmers don't comment their code. If it was hard to write, it should be hard to understand.

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Кстати, вот насчет вашего "наследования".

Неужели никому не пришло в голову почему нельзя редактировать? Всё же так просто и логично!

Да задумайтесь же вы уже разок о словах "наследование" и "редактирование". Что есть "редактирование наследованного контрола"? Это ИЗМЕНЕНИЕ "InitializeComponent()" БА-ЗО-ВО-ГО КЛАССА! Именно БАЗОВОГО!

Где хранится вся инициализация свойств контролов? Правильно, в коде. А что надо, чтобы в наследнике "передвинуть", например, TextBox в родителе? Переписать родительский "InitializeComponent()". Это и есть "грабли by-design" производства аналитиков майкрософта. Вот в Дельфи, там по-другому. Там используются ресурсы, а не код. Более правильно и логично. Жаль, что Хейлсберга наняли для разработки только C#, а не всей дотнети.

Есть вариант с "переопределяемым" InitializeComponent(). Но студия такого не понимает.

Так что пора бы этот вопрос закрыть раз и навсегда. И не заниматься ерундой. Архитекторы в МС в гробу видели всех девелоперов, которые хоть в чем-то не согласны с "правильной" точкой зрения. Их настоятельно просили вернуть "connected" режим — пофигу, рога в землю. Так же и с вашим "наследованием". Расслабтесь и получайте удовольствие.

—

Real programmers don't comment their code. If it was hard to write, it should be hard to understand.

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

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

Решил немного дополнить Ваше решение. Немного не корректно, но это первое, что пришло в голову.
[Designer(typeof(MyDesigner))]
public partial class ctrlSlyGrid : System.Windows.Forms.DataGridView
{
public ctrlSlyGrid()
{
InitializeComponent();
}
}

public class MyDesigner : System.Windows.Forms.Design.ControlDesigner
{
private List<System.Windows.Forms.DataGridViewColumn> _listNoneContainer = new List<System.Windows.Forms.DataGridViewColumn>();

public MyDesigner()
: base()
{

}
public override void Initialize(IComponent component)
{
base.Initialize(component);
System.Windows.Forms.DataGridView view = (System.Windows.Forms.DataGridView)base.Component;
foreach (System.Windows.Forms.DataGridViewColumn column in view.Columns)
if (column.Site == null)
_listNoneContainer.Add(column);
foreach (System.Windows.Forms.DataGridViewColumn column in _listNoneContainer)
if (view.Columns.Contains(column))
view.Columns.Remove(column);
}
protected override void Dispose(bool disposing)
{
System.Windows.Forms.DataGridView view = (System.Windows.Forms.DataGridView)this.Component;
foreach (System.Windows.Forms.DataGridViewColumn column in _listNoneContainer)
if (view.Columns.Contains(column))
view.Columns.Add(column);
base.Dispose(disposing);
}
}

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

BTA>Кстати, вот насчет вашего "наследования".

BTA>Неужели никому не пришло в голову почему нельзя редактировать? Всё же так просто и логично!

BTA>Да задумайтесь же вы уже разок о словах "наследование" и "редактирование". Что есть "редактирование наследованного контрола"? Это ИЗМЕНЕНИЕ "InitializeComponent()" БА-ЗО-ВО-ГО КЛАССА! Именно БАЗОВОГО!

ну, зачем же так уж сразу "ИЗМЕНЕНИЕ "InitializeComponent()""
можно ведь сказать "базовый класс должен знать, что он базовый" или "инициализация компонента должна зависеть от того, есть ли у конструктора наследники"

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

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

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

BTA>Да задумайтесь же вы уже разок о словах "наследование" и "редактирование". Что есть "редактирование наследованного контрола"? Это ИЗМЕНЕНИЕ "InitializeComponent()" БА-ЗО-ВО-ГО КЛАССА! Именно БАЗОВОГО!
Не правда (см. ниже).

BTA>Где хранится вся инициализация свойств контролов? Правильно, в коде.
Правильно.
BTA>А что надо, чтобы в наследнике "передвинуть", например, TextBox в родителе?
Изменить ему Location

BTA>Переписать родительский "InitializeComponent()".
Неправда (см. ниже).
BTA>Это и есть "грабли by-design" производства аналитиков майкрософта. Вот в Дельфи, там по-другому. Там используются ресурсы, а не код. Более правильно и логично. Жаль, что Хейлсберга наняли для разработки только C#, а не всей дотнети.
Ты не прав... попробуй (интереса для) создать унаследованную форму в студии. В базовой форме сделай один из контролов (к примеру — TextBox) с Modifier = protected.
Потом в дизайнере измени положение этого TextBox'а..
и посмотри в InitializeComponent() унаследованной формы... тым будет присвоение нового Location. вот и все грабли...
Надо просто сделать Modifier = ptotected для тех контролов, которые должны уметь меняться в классе-наследнике...

... << RSDN@Home 1.2.0 alpha rev. 0>>

На C# недавно и самым первым делом столкнулся с "проблемой" наследования форм. Перерыл весь форум, поискал в MSDN и пришел к выводу, что для успешной работы достаточно прочитать руководства по ссылкам, одну из которых я нашел как раз на rsdn:
1. http://msdn2.microsoft.com/en-us/library/bx1155fz.aspx
2. http://support.microsoft.com/default.aspx?scid=kb;en-us;316560

Да, тоже попался на эти грабли очень поздно.
Например, menuStrip тоже в наследованных формах менятся не позволяет.
Как решать это так и не нашел, зато нашел замену на
http://www.codeproject.com/cs/menu/magicmenucontrol.asp
Правда не так красиво, но можно и напильником достругать, благо код открытый.
c toolStrip-ом тоже самое, пришлось реализовывать свой toolStrip.

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

	От:	ice_croft
	Дата:	30.11.05 09:31
	Оценка:

	От:	hugo
	Дата:	30.11.05 10:30
	Оценка:

	От:	ice_croft
	Дата:	30.11.05 15:39
	Оценка:

	От:	hugo
	Дата:	01.12.05 07:18
	Оценка:

	От:	ice_croft
	Дата:	01.12.05 07:34
	Оценка:

	От:	Arthur Khakimov
	Дата:	15.03.06 16:47
	Оценка:

	От:	Hacker_Delphi
	Дата:	17.03.06 16:06
	Оценка:	8 (1)

	От:	Аноним
	Дата:	03.02.06 12:33
	Оценка:

	От:	Аноним
	Дата:	03.02.06 15:57
	Оценка:

	От:	Аноним
	Дата:	03.02.06 17:11
	Оценка:

	От:	Аноним
	Дата:	06.02.06 10:03
	Оценка: