Массив контейнеров с объектами внутри, программно!

[TrueTrue]

Подскажите, как программно создать Массив контейнеров с объектами внутри.

Есть PictureBox в нём ещё Picture, Label и ещё контролы. Мне нужно программно, создавать такой набор элементов. Размножить...

[Хакер]

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

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

[TrueTrue]

А что тут непонятно?) У автора ничего не получается))))

Я на форме создал PictureBox1(0) в него засунул Label1(0) и ещё PictureBox2(0)

Программно, в цикле, делаю Load PictureBox1(1) и надеюсь на то, что PictureBox2(1) и Label1(1) создаются параллельно и уже находятся внутри PictureBox1(1), но я ошибся.(((

[Debugger]

Создай User Control и в нём размести Label1 и PictureBox2.
Создай на форме UserControl(0), затем вызывай Load UserControl(1) и ещё одна пара Label1 и PictureBox2 создастся автоматически.

В архиве - пример. В контроле надпись ucLabel и бокс ucPictureBox. Чтобы была возможность доступа к этим контролам извне, я сделал две функции в контроле: Label1, которая возвращает ссылку на ucLabel и PictureBox2, которая возвращает ссылку на ucPictureBox.
Соответственно, можно к ним обращаться: UserControl1.Label1.Caption = "Надпись".

UserControl.rar

(1.62 Кб) Скачиваний: 110

Удачи.

[Хакер]

Какой User Control, всё делается без User Control-а.

cloning+children.zip

(7.5 Кб) Скачиваний: 133

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

[TrueTrue]

Сорри, за долгий ответ. Спасибо огромное за помощь, всё получилось))))

[ger_kar]

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

А можно немного поподробнее? Чем такой способ плох? Хотелось бы не просто знать, а знать почему именно. Я пару раз так делал, все вполне хорошо себе работало. И если такой способ плох, то чем его лучше заменить?

[Qwertiy]

Чем такой способ плох?

Куча лишнего кода. К тому же, противоречит принципам ООП. Да и здравому смыслу тоже. Если нужен контейнер, который повторяется вместе с содержимым, то логично его заменить одним контролом.

[ger_kar]

К тому же, противоречит принципам ООП

Странно, а в чем противоречие то? Наоборот смысл же ООП в том, что-бы можно было создать или используя готовый контрол, создать столько его экземпляров, сколько потребуется. Как может создание множества объектов одного типа противоречить ООП? С другой стороны, какой смысл создавать свой контрол, тратить на это кучу времени и писать кучу кода, а потом сделать его в одном экземпляре, вместо того, что-бы просто породить нужное количество стандартных готовых контролов или их комбинаций. По крайней мере я именно так и рассуждаю.

[Qwertiy]

К тому же, противоречит принципам ООП

Странно, а в чем противоречие то? Наоборот смысл же ООП в том, что-бы можно было создать или используя готовый контрол, создать столько его экземпляров, сколько потребуется. Как может создание множества объектов одного типа противоречить ООП? С другой стороны, какой смысл создавать свой контрол, тратить на это кучу времени и писать кучу кода, а потом сделать его в одном экземпляре, вместо того, что-бы просто породить нужное количество стандартных готовых контролов или их комбинаций. По крайней мере я именно так и рассуждаю.

Не понял, с чем ты споришь. Ты то же самое говоришь, что и я.

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

Для единственного экземпляра, естественно, в большинстве случаев контрол не нужен. Хотя, я иногда так делаю, закладывая в контрол некую логику и фактически создавая связку класс - контрол для его редактирования (со свойством Value, через которое можно получить текущее содержимое). Удобно с точки зрения разделения кода.

За счёт чего с контролом больше кода чем без него? Если ты об отсутствии нормального наследования, то это недостаток VB6. Кода должно получиться меньше, а не больше.

[Хакер]

А можно немного поподробнее? Чем такой способ плох? Хотелось бы не просто знать, а знать почему именно. Я пару раз так делал, все вполне хорошо себе работало. И если такой способ плох, то чем его лучше заменить?

Контрол ScrollBar не состоит из трёх контроллов CommandButton, как в это кому-то бы хотелось верить.
Контролы-таблицы не состоят из массивов контролов-строк.
Гриды не состоят из двухмерных массивов TextBox-ов.
ToolBar не состоит из массивов контролов кнопок.
Меню не состоят из массивов Label-ов/Static-ов.

Во-первых, есть контролы Windows, базирующиеся на окнах и окнных классах, стилях и сообщениях.
Во-вторых, есть COM-контролы, надстроенные над первым механизмом, и базирующиеся на COM-классах.

Очевидно, что вторая концепция является на порядок более тяжеловесной, потому что объём теневой работы существенно больше.

Но даже если говорить о первом, то подход, когда один контрол составляется из нескольких вложенных является очень редко удачным. Он может быть удачным, если требуется скопировать идентичное поведение, и особенно, если изменение (когда либо в будущем возможно осуществимое) во вложенном контроле по логике проекта должно сказаться на изменении поведения внешнего контрола. Это приемлемый случай. И совершенно неприемлемый случай: когда вложенный контрол используется для отображения повторяющихся данных (например набора строк таблицы, ячеек сетки, иконок и чего угодно ещё).

Так, например, ListView в режиме Report для отображения заголовка колонок использует отдельный вложенный контрол, но для отображения строк — ни в коем случае. Это хороший пример того, как надо выбирать между использованием вложенного контрола и его неиспользованием.

Основное правило: чем большая часть врутренностей контрола отрисовывается вручную на белом холсте, то есть с нуля, методами GDI, тем лучше.
Причина в том, что окна (например те же кнопки и эдитбоксы), и плюс создаваемая на каждое (любое) окно пара DC — дорогой ресурс. Не настолько дорогой, чтобы вообще отказаться от окон внутри окон своих приложений, но невероятно дорогой, чтобы использовать массивы контролов для отображения повторяющихся элементов внутри других контролов.

Нужно понимать, что ваше приложение могут открыть одновременно 10 раз, и будет ещё открыто 50 окон Paint-а и столько же ещё чего-нибудь. Вы, возможно, проверяете, достаточно ли быстрое ваше приложения, но вы проверяете его в неприлично хороших условиях: обычно процессору в подобных случаях вообще почти ничего не приходится выполнять кроме единственного потока вашего приложения, в working set вашего процесса никак не изменяется. Это наилучшие условия, и они не показательны, потому что бывают ещё средние условия и наихудшие условия, и лучше смотреть по ним.

Простой пример того, как проверить тупизну вашего GUI в не самых лучших для него условиях — откройте кучу всего, включая несколько экземпляров вашего приложения и измените workarea. Для этого, например, измените размер панели задач или панели инструментов, прилепленной к краю экрана, если она есть, или размер окна мессенджера (например ICQ), если он есть и прилеплен к краю экрана. Вы получите весьма долгий зависон, в связи с тем, что все окна сразу получат сообщение об изменившейся clientarea и начнут реагировать на это перемасштабированием себя самих и своих внутренностей. Это очень долгий и тяжёлый процесс.

И подобных ситуаций — куча.
Основное массовое заблуждение: люди делают тупой медленный GUI, но не верят в это. На всякий случай они проверяют своей GUI в абсолютно необъективных условиях, в тек, которых их тупой медленный GUI заведомо даст хороший результат. Проверяют, и ещё больше укрепляются в уверенности, что их GUI достаточно хорош. На самом деле их GUI критически туп и медлен. Касается не только GUI, а приложений вообще.

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

Это всё было сказано относительно первой концепции контролов — с помощью окон, оконных классов, сообщений и стилей.

Над всем этим надстроена ещё большее тяжеловесная концепция встраиваемых куда-угодно OLE-контролов, aka COM-контролов, aka ActiveX-контролов. Очевидно, что раз она ещё более тяжеловесная, то практиковать тот же принцип с использованием множимых контролов для визуальной репрезентации повторяющихся элементов.

___________

Есть ещё второй момент. Первый касался того, что в гриде 100×20 все внутренности должны быть нарисованы вручную, а не созданы с помощью двух тысяч эдитбоксов. То есть того, что повторяющиеся визуальные элементы делать с помощью повторяющихся контролов — криминально.

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

В этом случае есть вторая тупость, относящаяся к писанию о лени. Тупость состоит в том, что если нужно создать свой собственный контрол ListBox, в котором будет содержаться всего 500 строчек, хотя одновременно отображаться могут только 23 (больше не влазит в габариты бокса), глупые программисты будут плодить 500 копий контролов, по одному контролу для каждого пункта списка, и будут тягать (то есть двигать вверх-вниз) всю эту армию из 500 копий контролов в ответ на скроллинг своего ListBox-а. В то время, как правильным былом бы создать массив всего-лишь из 17 копий контролов, при скроллинге двигать блок из 16 копий, а 17-ый переставлять с верхушки вниз (или снизу вверх, в зависимости от направления скроллинга) и просто напросто менять ему текст.
Это в 30 раз быстрее, или в 300 раз быстрее, если бы пунктов было не 500, а 5 тысяч.

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

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


Есть например ещё такая шиза. Для отображения форматированного текста используют контрол RichEditBox. Правда заключается в том, что для отображения форматированного текста ничуть не сложнее, а в добавок ещё и в 1000 раз быстрее — отрисовывать форматированный текст вручную. Применение RicheditBox-а оправдано тогда и только тогда, когда форматированный текст нужно не только отображать, но и давать возможность его редактировать.
Наверное этим топиком. Там же пример отображения форматированного текста просто ручной отрисовкой.

[Qwertiy]

А можешь рассказать, как это устроено в WPF, когда задаются составляющие части контрола?

[Хакер]

Не в курсе.

[arthur2]

Есть например ещё такая шиза. Для отображения форматированного текста используют контрол RichEditBox. Правда заключается в том, что для отображения форматированного текста ничуть не сложнее, а в добавок ещё и в 1000 раз быстрее — отрисовывать форматированный текст вручную.

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

[Хакер]

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

Если делать вывод как в том топике, то да. Но в том топике написано, в каких случаях применим тот код. Для вывода тултипа с информацией по аргументам функции он подходит идеально. И почему разработчики VB использовали рич — не понятно.

[Qwertiy]

Есть же локализованные версии среды...

[Хакер]

И что? Как это влияет на подсказку об аргументах?

[ger_kar]

Контролы-таблицы не состоят из массивов контролов-строк

А я именно так кстати и думал, в том смысле, что состоят из массивов контролов-строк.

Основное правило: чем большая часть врутренностей контрола отрисовывается вручную на белом холсте, то есть с нуля, методами GDI, тем лучше.Причина в том, что окна (например те же кнопки и эдитбоксы), и плюс создаваемая на каждое (любое) окно пара DC — дорогой ресурс. Не настолько дорогой, чтобы вообще отказаться от окон внутри окон своих приложений, но невероятно дорогой, чтобы использовать массивы контролов для отображения повторяющихся элементов внутри других контролов

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

Простой пример того, как проверить тупизну вашего GUI в не самых лучших для него условиях — откройте кучу всего, включая несколько экземпляров вашего приложения и измените workarea.

И еще лучше это проделать на стареньком дохленьком компьютере, современные то стоят далеко не у всех

Тупость состоит в том, что если нужно создать свой собственный контрол ListBox, в котором будет содержаться всего 500 строчек, хотя одновременно отображаться могут только 23 (больше не влазит в габариты бокса), глупые программисты будут плодить 500 копий контролов

Ну я такое точно никогда не делал , хотя и до идеи перестановки первого/последнего контрола тоже не додумался, я просто менял содержимое.

Ну и конечно большое спасибо за такой расширенный и познавательный ответ.

И что? Как это влияет на подсказку об аргументах?

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

[Хакер]

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

Я бы не сказал. По крайней мере, если попробовать написать ListBox на основе множимых Label-контролов и на основе отрисовки, я сильно сомневаюсь, что первый вариант выиграет у второго по объёму коду.
А во-вторых, ну такова уж жизнь: или вы пишите правильный контрол сами, или вы покупаете правильный контрол. Или вы быдлокодер, и делаете неправильный контрол сам.

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

Ну и что?
Я буду спрашивать «ну и что», пока кто-нибудь не скажет, что же такое надо написать в коде, чтобы тултип, сделанный как я показал, сломался бы.

[Qwertiy]

Я буду спрашивать «ну и что», пока кто-нибудь не скажет, что же такое надо написать в коде, чтобы тултип, сделанный как я показал, сломался бы.

Конкретно написанный тобой вариант? Что будет, если текст пишется справа налево? Как минимум, он не появится из-за начальной позиции (0, 0). А может и ещё что-нибудь выплывет...

[Хакер]

Qwertiy, ты перед тем как написал, подумал, что текст в IDE не может писаться справа налево?

[Qwertiy]

Почему не может? А если он на арабском? IDE чем-то отличается от текстового редактора?

[Хакер]

Почему не может? А если он на арабском? IDE чем-то отличается от текстового редактора?

Потому что не может. Кодебокс сам выводит текст отрисовывая его по-словно, как и мой пример. Только в кодебоксе при отрисовки «слов» меняется цвет, а у меня в примере — начертание.

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

[Qwertiy]

Если не может, то это её недоработка.

[Хакер]

Это не недоработка. Никто не сможет ясно сказать, по каким правилам должен отображаться код, который представляет собой кашу из LTR и RTL текста.

И уж точно будет катастрофа, если отображать его по правилам, используемым обычными (не расчитанными на код) текстбоксами.

[Qwertiy]

Это не недоработка. Никто не сможет ясно сказать, по каким правилам должен отображаться код, который представляет собой кашу из LTR и RTL текста.

VS 2010 это позволяет.

[Хакер]

Тоже мне нашёл эталон...