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

P>Мне всегда говорили, что половина решения задачи содержится в правильной ее (задачи) постановке. Похоже что ты ринулся решать второстепенную проблему (создание диалога из памяти), до конца не продумав главную. Идея снабдить ListView шибко крутым интерфейсом напихав в него дочерних контролов (Ого! Ты даже до дочерних диалогов додумался! )

Хмм.
Вообще я сейчас вспомнил, что первый раз до такой штуки я додумался и реализовал более 10 лет назад, когда писал конвертеры для баз данных. Там надо было на ходу накидывать входящие поля и выбирать куда они будут перекочёвывать. Окно-контейнер имело скролл-бар и динамический набор дочерних диалогов, с кнопками управления и комбобоксом со списком полей экспортируемой базы данных.
И ещё один момент — это не ListView, он мне не подходит. Точнее, в процессе разработок я сделал свой лист-дерево, поэтому мне удобнее его использовать.

P>кажется привлекательной. Но только на первый взгляд. Ну допустим, научился ты создавать свои диаложки и напихал их в ListView, а дальше что? В общем дам тебе две проблемы, которые... [я в свое время решить не смог, поэтому отказался от этой идеи]. Что будешь делать в случае:
P>1. Сжатия/расширения SubItem-ов тасканием за Header (полностью решается только убийством хидера на корню: нет хидера — нет проблемы )
У меня нету сабитемов, за ненадобностью.
P>2. ScrollBar-ы в твоем ListView. Ну как, скажи мне, ты собрался перетаскивать дочерние диалоги согласно тасканию пимпочки на скролбаре? А клавиатурный скрол не забыл?
Не забыл, это давно уже сделано, есть скролливание под фокус при клавиатурном вводе. Так как задумывалось дерево, я сделал возможность добавить тул-разрёртыш (который в обычном дереве [+], сначала и у меня был [+], но люди сказали "щас так не модно, модно кнопка с шевроном"... ну, блин, вот теперь у меня кнопка с аппаратным шевроном по умолчанию... хотя можно на неё влепить любую картинку на каждое состояние). Плюс, само наличие диалогов я заложил в лист изначально, где-то это даже использовалось. Диалог в итеме не виден, пока expand не нажмёшь. Там же под экспандом сидят дочерние итемы. Скроллбары работают. У меня ещё есть возможность обратного порядка заполнения, от низа к верху, как в фотошопе. Кроме скролинга у меня присутствует expand и ресайзинг и диалоги на дочерних итемах. И каждому итему можно задать персональную высоту. И всё это учитывается при скролинге, expand-е и ресайзе. Expand/collapse/переход на парента — с клавиатуры тоже можно. (Multi)выделение с shift/ctrl. Есть драг-н-дроп(но для дерева ещё не доделан нормально), с подсветкой. И весь этот зоопарк нотифаит родительское окно по клаве/мыши/change/command/drop и имеет возможность внешнего расширения итемов, так что можно делать навороты дальше, не меняя основной класс окна. Я не первый год делаю свои окна. Так что всё ок.
P>3. А если строчек 10 тыщ? Система не охренеет от такого количества дочерних диалогов?
Охренеет ещё на трёх тысячах, в моём случае, но мне пока надо штук 10 максимум. По хорошему, конечно, надо динамически их создавать, но будем решать проблемы по мере их поступления(к тому же статика ближе к вышеописанной системе шаблонов-параметров, которые биндятся на старте). Три-четыре проекта назад я решил эту проблему просто подъёмом отдельных больших диалогов с настройками, так как настроек там было дофигищи на каждый итем, 2-4 закладки, с некоторых ещё диалоги поднимались... так что этот зоопарк в лист не влез бы. Но сейчас всё по-другому, один итем — оди параметр, а то я бы и сейчас сделал так же, но для одного параметра как-то странно подымать диалог.

P>В общем после размышлений я выбрал более-менее стандартную в таких случаях схему: Лист оставляем листом как есть, все эффекты делаем чезез StateImages (элементарно) / NM_CUSTOMDRAW (для продвинутых), а контрольчики (точнее один-единственный контрольчик) создаем в момент клика по SubItem-у и прямо на месте этого SubItem-а. После того, как юзер отредактировал элемент, достаем данные и з контрольчика, запихиваем их в лист и прибиваем контрольчик нахрен [Подсказка для быдлокодеров:

	Скрытый текст
	"прбиваем контрольчик нахрен" означает P> P>::PostMessage(hWndControl, WM_CLOSE, 0, 0); P> P> Не вздумай вызывать DestroyWindow в обработчике нотификации от этого контрола! Почему? Ну, когда программа рухнет — поймешь

].
А так я делал восемь-девять лет назад, когда надо было копировать свойства окна из таблички. Программа была на MFC, контрол я не убивал, а скрывал, потому как он был mfc-шный и сам создавался/убивался вместе с окном свойств.
P>При такой схеме набор контрольчиков существенно ограничен, но кое на что сгодится и такой. Что можно сделать?
P>[...]
Эту схему уже те же 10 лет мы используем на работе, только не на ListView а на другой таблице, но принцип тот же. Только спинов у нас нету, так как не нужны, а кнопки и чеки у этой таблицы штатные. Остальное ровно так же.

P>От слайдеров думаю придется отказаться. С ходу не придумаю как их туда воткнуть.
да слайдер-то туда можно воткнуть и обработать, проблема в том, что он не информативен сам по себе. Нужен сбоку едит/статик, который показывает, каково значение на данный момент. А на едите полезен спин, чтоб сразу колесом его менять. Сразу получаем те самые три контрола.
P>В общем как-то так. Ну или если решишь как быть со скролами/хидерами — напиши мне как.
С хидерами проблему можно попробовать решить через нотификации, хедер при смене размера-положения заголовков шлёт нотификации родителю. Я на это раньше затачивался, у меня была таблица, во второй колонке были числовые значения, и чтоб сэкономить место, я размещал там кнопку-чек "hex", при нажатии на которую значение выводилось в 16-м виде, при отжатии — в 10-м. Вот чтоб размещать кнопку в правильном месте, затачивался на нотификации от хедера. Но вот не помню, получилось у меня это полностью сделать или нет.