сделать для формы (фрейма, WinControl) аналог Begin/EndUpdatе

← →
Игорь Шевченко © (2009-06-03 16:31) [0]

Ситуация следующая: на ScrollBox расположено несколько фреймов, в каждом фрейме несколько контролов. По определенным условиям определенные контролы становятся невидимыми и те, что под ними, поднимаются на их место. Соответственно, общая высота фрейма тоже подстраивается.

Все бы хорошо, но медленно, потому что при каждом изменении свойства Visible, Top и.т.п контролы начинают обмениваться массой сообщений.
Сообщениями они не обмениваются только в случае csLoading in ComponentState или если не создан Handle окна для наследников TWinControl.

Немного помогает DisableAlign ... заполнение контролов, расчет видимости и положения...EnableAlign

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

Фреймов много, контролов на каждом фрейме тоже много.

← →
Хитрий Лис (2009-06-03 16:36) [1]

LockWindowUpdate() ?

← →
Игорь Шевченко © (2009-06-03 16:54) [2]

> LockWindowUpdate() ?

Это с самого начала сделано

То есть, общая последовательность такая

LockWindowUpdate (ScrollBox.Handle);
try
...
создание и заполнение тысячи фреймов, включая расчет видимости контролов каждого
...
finally
LockWindowUpdate(0);
end;

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

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

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

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

← →
pasha_golub © (2009-06-03 18:06) [3]

> создание и заполнение тысячи фреймов

Огого... Скрин можно одним глазком? Попугаться на ночь :)

← →
oxffff © (2009-06-03 18:20) [4]

> Игорь Шевченко © (03.06.09 16:31)

Запретить неизвестному VCL контролу слать сообщения не удастся.

Но погасить реакцию на них можно.
Рекомендации.
-перекрытие Tobject.Dispatch
-перекрытие WndProc
-програлатывание WMPAINT у WndProc в качестве достойной замены
LockWindowUpdate

← →
clickmaker © (2009-06-03 18:24) [5]

WM_SETREDRAW ?

← →
Игорь Шевченко © (2009-06-03 18:39) [6]

oxffff © (03.06.09 18:20) [4]

Дело не в WM_PAINT - до него не доходит.
Контролы обмениваются сообщениями WM_WINDOWPOSCHANGING, WM_MOVE, WM_SIZE, CM_CHANGED и т.п.

Менять у всех контролов Dispatch - а как ты себе представляешь такую замену, а заодно и восстановление, для нормальной работы.

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

← →
oxffff © (2009-06-03 19:02) [7]

> Менять у всех контролов Dispatch - а как ты себе представляешь
> такую замену, а заодно и восстановление, для нормальной
> работы.

Технически вам никто не мешает заменить (вне рамок ООП)

1.
TControl = class(TComponent)
private
FParent: TWinControl;
FWindowProc: TWndMethod;

2. TControl.procedure WndProc(var Message: TMessage); virtual;

Вопрос как сделать красиво, чтобы design time работал.

1a. Пропатчить VMT нужных классов run time для всех экземпляров зтих классов.
1.б. Патчить ссылку на VMT только у нужных объектов.

2. Пропатчить

procedure TObject.Dispatch(var Message);
asm
<- inject code run time
PUSH ESI
MOV SI,[EDX]

3. Пропатчить

procedure Tcontrol.WndProc(var Message: TMessage);
<- inject code run time

4. Пропатчить

procedure TWinControl.WndProc(var Message: TMessage);
<- inject code run time

5. До кучи, если так необходимо.

Пропатчить

procedure TWinControl.MainWndProc(var Message: TMessage);
<- inject code run time

Решение не из совсем простых. Но и задача соответсвующая.
Но решаемая с минимумом кода.

← →
oxffff © (2009-06-03 19:12) [8]

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

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

procedure Tcontrol.WndProc(var Message: TMessage);
с кодом

IF SuppressWnd then exit;
inherited WndProc(Message)

или

procedure Tobject.Dispatch

← →
Игорь Шевченко © (2009-06-03 19:18) [9]

oxffff © (03.06.09 19:12) [8]

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

Мне б несколько другое - мне б какой-то глобальный механизм задействовать, я уже писал, что при csLoading in ComponentState контролы сообщения не посылают.

Я к чему - может я недостаточно тщательно Controls.pas и Forms.pas изучал и пропустил какой механизм...

← →
Медвежонок Пятачок © (2009-06-03 19:21) [10]

все переписать на асп.нет с помошью мультивью
:)

← →
Игорь Шевченко © (2009-06-03 19:22) [11]

Медвежонок Пятачок © (03.06.09 19:21) [10]

Тогда еще больше тормозить будет :)

← →
oxffff © (2009-06-03 19:29) [12]

> Игорь Шевченко © (03.06.09 19:18) [9]
> oxffff © (03.06.09 19:12) [8]
>
> Идея понятна, но слегка затруднительна - это мне для каждого
> контрола надо создавать враппер и в дизайн-тайме именно
> этот враппер класть, потому что контролы находятся в ран-
> тайм пакетах.

Совсем необязетельно. cм. [7]-1a

Написать придется только вызов

procedure PatchVMT(Classes:Array of Tclass);
var Aclass:Tclass;
begin
for Aclass in Classes do PPointer(@(pbyte(Classes)[offset to WndProc])))^ = @MyFunc;
end;

PatchVMT([Tbutton, Tedit, TmyFrame.....]);

← →
oxffff © (2009-06-03 19:31) [13]

> PatchVMT([Tbutton, Tedit, TmyFrame.....]);

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

TMyButton=class(TButton)
end;

PatchVMT([TMyButton.....]);

:)

← →
Игорь Шевченко © (2009-06-03 19:49) [14]

oxffff © (03.06.09 19:31) [13]

Не работает. Может, по теории оно и должно сработать, но на практике получается фигня. Контролы зависят-таки от сообщений :)

← →
oxffff © (2009-06-03 22:23) [15]

> Игорь Шевченко © (03.06.09 19:49) [14]
> oxffff © (03.06.09 19:31) [13]
>
> Не работает. Может, по теории оно и должно сработать, но
> на практике получается фигня. Контролы зависят-таки от сообщений
> :)

Естественно зависят.
Но никто не запрещает пропускать только подмножество сообщений CM_*.
Здесь от вас(ваших действий по оптимизации) зависит какую часть множества сообщений вы хотите пропустить, а в момент предъявления пользователю.

← →
Игорь Шевченко © (2009-06-03 22:52) [16]

oxffff © (03.06.09 22:23) [15]

Увы, твое предложение лишено разумного смысла. Например, отображение Edit зависит от WM_SETTEXT, отображение CheckBox зависит от BM_SETCHECK, и т.д.
Прописывать все это в коде, да еще и отлаживать потом - это слишком длинная и чреватая ошибками работа.

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

Собственно, тормоза ограничиваются 5..10-ю секундами при отображении десятка тысяч контролов, если не получится радикально (и безболезненно с точки зрения трудозатрат) ускорить - придется подождать, такие объемы встречаются не часто, в основном порядка тысячи-двух контролов на картинку, а то и меньше.

← →
oxffff © (2009-06-03 23:07) [17]

> Игорь Шевченко © (03.06.09 22:52) [16]
> oxffff © (03.06.09 22:23) [15]
>
> Увы, твое предложение лишено разумного смысла.

Я решал задачу

> Все бы хорошо, но медленно, потому что при каждом изменении
> свойства Visible, Top и.т.п контролы начинают обмениваться
> массой сообщений.

Но не обратил внимание на

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

Чую бухгалтерские отчеты меня делают не внимательным.

:)

Тогда естестенно для всех оберточных windows object контролов(Tedit, TButton, Tmemo.... ) запретить сообщения нельзя.
То есть насколько я понимаю вопрос исчерпан.
Ответ дан вами сами в [14].

> Контролы зависят-таки от сообщений

← →
Mystic © (2009-06-03 23:13) [18]

Такой изврат так brainstorm idea. Сохранить TScrollBox в DFM, изменить нужные свойства и загрузить обратно?

← →
oxffff © (2009-06-03 23:19) [19]

> Mystic © (03.06.09 23:13) [18]

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

← →
Mystic © (2009-06-03 23:25) [20]

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

> Мне б несколько другое - мне б какой-то глобальный механизм
> задействовать, я уже писал, что при csLoading in ComponentState
> контролы сообщения не посылают.

← →
Игорь Шевченко © (2009-06-03 23:28) [21]

oxffff © (03.06.09 23:07) [17]

В любом случае спасибо за участие.

Вопрос не то, чтобы исчерпан, путем перестановки вызовов SetParent после заполнения фрейма и подгонки его размеров и внутренностей под данные, путем установки свойства Visible в общем предке всех фреймов в false, и переустановке его в true после, опять же, заполнения и подгонки, путем запрета выравнивания на время установки свойств компонентов мне удалось ускорить вывод всей этой массы контролов (ну скажем, на 50% по сравнению с первоначальным вариантом), так что обсуждение в любом случае представляет практическую ценность.

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

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

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

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

Вот когда выборка большая, при отображении начинаются тормоза (померено, именно при отображении, а не при выборке).

Может, я велосипед изборетаю и есть более разумное решение ?

← →
Игорь Шевченко © (2009-06-03 23:33) [22]

Mystic © (03.06.09 23:13) [18]

> Такой изврат так brainstorm idea. Сохранить TScrollBox в
> DFM, изменить нужные свойства и загрузить обратно?

Думал :)
Но это тоже динамическое создание компонент конкретно по месту, от чего бы мне хотелось уйти

← →
Petr V. Abramov © (2009-06-03 23:43) [23]

> Может, я велосипед изборетаю и есть более разумное решение
> ?

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

← →
тимохов © (2009-06-03 23:45) [24]

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

Прямо так бы и создавал контролы в скроллбоксе без всяких там фреймов, элайнов, анкоров и прочей тормозящей функциональности.

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

Хотя тут все зависит от целевого использования данного механизма. Точнее - от частоты предполагаемых изменений в будущем.

ЗЫ Излагал ессесно из моего понимания описания задачи. Может я понял не так.

← →
Игорь Шевченко © (2009-06-03 23:55) [25]

Petr V. Abramov © (03.06.09 23:43) [23]
тимохов © (03.06.09 23:45) [24]

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

Я не совсем представляю, какой можно аналогичный пример привести, но допустим:

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

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

← →
Игорь Шевченко © (2009-06-03 23:58) [26]

тимохов © (03.06.09 23:45) [24]

Почему не хочу динамически - потому что нарисовав фрейм я сгруппировал данные логически. Причем, с одной точки зрения логическая группировка одна, с другой - другая, с третьей - третья. Я ее (группировку) вижу и могу показать другому, дескать, устраивает тебя так или ты хочешь иначе сгруппировать ? Если иначе - нарисовал другой фрейм и все радостно.

Делать такие вещи в динамике мне представляется недостаточно наглядным :)

← →
oxffff © (2009-06-04 00:03) [27]

> Mystic © (03.06.09 23:25) [20]

При csLoading и csReading in ComponentState контролы могут делать все что угодно, в том числе и слать сообщения. Это не запрещено.

← →
Petr V. Abramov © (2009-06-04 00:14) [28]

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

а эволюцию вселенной от Большого Взрыва до Большого Агромного Коллайдера не хочется отобразить?
Я бы пошел от дизайна формы, на котором макс информации в разумных пределах, и при этом любая фигня (телефоны, личная жизнь) детализируется максимально быстро и чтоб даже дурак догадался, где кнопка детализации.
На экране один фиг все не уместишь, а если уместишь, то здохнешь че на этом экране найти.
Говорят, 5-7 - волшебгое число, что подчиненных, которыми можно эффективно управлять, это "сущностей" на экране, в которых внимание не рассеишь, копаясь.

← →
Игорь Шевченко © (2009-06-04 00:20) [29]

Petr V. Abramov © (04.06.09 00:14) [28]

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

Было с отдельной детализацией - неудобно. Как выяснилось, обычно люди смотрят на детализированное изображение и сразу находят те куски, которые им надо.

Когда ты смотришь на веб-страницу, скажем, мастаков, ты там не всегда видишь кнопку детализации. И количество веток больше, чем 5-7 тебя тоже не удивляет. Вот представь, что вместо начальных двух-трех строк из первого поста каждой ветки там было по одной-две строки каждого поста с первой страницы.

← →
Германн © (2009-06-04 00:21) [30]

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

Мне аж страшно стало! Значит теперь и авиакомпании на нас досье будут заводить?
)))

← →
MsGuns © (2009-06-04 00:23) [31]

>Игорь Шевченко © (03.06.09 23:28) [21]

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

Суть задачи была сродни твоей - есть БД с кучей таблиц - надо было нарисовать софт для универсального отображения-корректировки любого набора полей любой таблмцы (или смеси их).

← →
sniknik © (2009-06-04 00:23) [32]

> Может, я велосипед изборетаю и есть более разумное решение ?
может TDBCtrlGrid?

← →
Игорь Шевченко © (2009-06-04 00:27) [33]

MsGuns © (04.06.09 00:23) [31]
sniknik © (04.06.09 00:23) [32]

Гриды были. Неудобно. Грид широкий и скролировать его в двух направлениях в поисках нужной информации настолько никуда не годится, что о гридах лучше не вспоминать.

> надо было нарисовать софт для универсального отображения-
> корректировки любого набора полей любой таблмцы (или смеси
> их).

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

Для универсальных корректировок существует масса неудобных инструментов :)

← →
Petr V. Abramov © (2009-06-04 00:30) [34]

> Игорь Шевченко © (04.06.09 00:20) [29]

из [25] я предствил себе форму, на которой мастаки отобраны, например, для приличия, по возрасту, и на ней же, на том же экране, статискика статистика постов в конференциях, история участия в ММР со всеми подробностями, фрагменты постов, сцылки на резюме ...

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

← →
Игорь Шевченко © (2009-06-04 00:33) [35]

MsGuns © (04.06.09 00:23) [31]
sniknik © (04.06.09 00:23) [32]

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

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

← →
тимохов © (2009-06-04 00:45) [36]

> Игорь Шевченко © (03.06.09 23:58) [26]

Одну вещь тебе скажу. Немного филосовскую.

По моему мнению дзен начинается там, где ты достигаешь уровня, чтобы понять - пора создавать свой DSL (domain specific language). Delphi со своим design-tim"ом - тоже DSL: той предметной области, которую видят разработчики среды.

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

В общем тут важно что? Понять, а нужно ли упираться в стандарт - может он тебя только держит. Может ты напряжешься денек, напишешь свою библиотечку под это дело, опишешь ее. И будет внятнЕй и понятней, чем сейчас?

В общем - я бы написал свое )

← →
Игорь Шевченко © (2009-06-04 00:51) [37]

тимохов © (04.06.09 00:45) [36]

Серьезную вещь за денек не напишешь, а на несерьезную тратить время не стоит.

Delphi в данном случае удобна чем - можно быстро надизайнить, посмотреть, повертеть со всех сторон, не понравилось - написал иначе.

В принципе, я задавал вопрос на тему, может, существует какая-то неизвестная мне гайка/набор гаек, которые позволят безболезненно сделать аналог BeginUpdate/EndUpdate.

Если не существует, ну что же - будем с тормозами жить :)

← →
Eraser © (2009-06-04 03:55) [38]

а как оно себя ведет в висте, с включенным аеро?

← →
oxffff © (2009-06-04 09:17) [39]

> Игорь Шевченко © (04.06.09 00:51) [37]

Посмотрите oxffff © (04.06.09 00:03) [27].
При csLoading и csReading in ComponentState посылка сообщения проиходит.

Однако вот код который подавляет обработку(хотя для произвольных контролов никто не мешает обработать)

procedure TWinControl.DefaultHandler(var Message);
begin
if FHandle <> 0 then
begin

Отсюда делаем вывод. Нужно устанавливать 0
(не не будем же рушить окно :) ) до вашей обработки.
И востанавливать после.

← →
Игорь Шевченко © (2009-06-04 10:43) [40]

oxffff © (04.06.09 09:17) [39]

[39]

> При csLoading и csReading in ComponentState посылка сообщения
> проиходит.

[27]

> При csLoading и csReading in ComponentState контролы могут
> делать все что угодно, в том числе и слать сообщения. Это
> не запрещено.

Тебе не кажется, что это несколько разные утверждения ? То есть, наличие МПХ у индивидуума еще не означает, что он тут же начнет насиловать все, что движется.

> Однако вот код который подавляет обработку(хотя для произвольных
> контролов никто не мешает обработать)
>
> procedure TWinControl.DefaultHandler(var Message);
> begin
> if FHandle <> 0 then
> begin
>
> Отсюда делаем вывод. Нужно устанавливать 0
> (не не будем же рушить окно :) ) до вашей обработки.
> И востанавливать после.

Все у тебя по теории хорошо, но без практики она мертва. Ты забываешь, что есть TGraphicControl и его наследники, ты забываешь, что есть такой способ вызова обработчика сообщений, как Perform.

← →
oxffff © (2009-06-04 12:00) [41]

> Игорь Шевченко © (04.06.09 10:43) [40]

От куда вы сделали вывод, что я забыл про Perform?

Так давайте по сути.
Twincontrol также может слать сообщения через perform что и что делает при загрузки(то есть csLoading). См. Tedit.Text(Tcontrol.SetText).

И вообще причем здесь Perfrom?

Я стараюсь сократить множество обрабатываемых сообщений. Естестественно для произвольных контролов которые безусловно обрабатывают в WndProc сообщения это сделать не удасться в общем виде. Однако для контролов которые являются оберткой над стандартным windows object можно во всяком случае запретить дохождение до DefWndProc через установку handle в 0.

← →
oxffff © (2009-06-04 12:05) [42]

> Игорь Шевченко © (04.06.09 10:43) [40]

Это я вам отвечаю на первую часть.

Вот ваш первый пост.

> Сообщениями они не обмениваются только в случае csLoading
> in ComponentState или если не создан Handle окна для наследников
> TWinControl.

Это некорректное утверждение. В том смысле что здесь вы пытаетесь связать обмен сообщениями с наличием handle или отсутствием csLoading.

← →
vuk © (2009-06-04 12:16) [43]

Игорь, а ты еще не посмотрел, где у тебя основные потери времени - на создании экземпляров или на изменении свойств?

← →
Игорь Шевченко © (2009-06-04 12:17) [44]

oxffff © (04.06.09 12:00) [41]

Я могу еще раз повторить - теория мертва без практики.

> От куда вы сделали вывод, что я забыл про Perform?

Из приведенного кода TWinControl.DefaultHandler - вызовы Perform к нему не относятся.

> И вообще причем здесь Perfrom?

При том, что контролы могут вызывать свои и родительские обработчики сообщений через вызов Perform

> Это некорректное утверждение. В том смысле что здесь вы
> пытаетесь связать обмен сообщениями с наличием handle или
> отсутствием csLoading.

Это корректное утверждение.

В коде для наследников TWinControl встречаются фразы if HandleAllocated then ...

В коде для наследников TControl, соответственно
if csLoading in ComponentState then (как вариант if csReading) then

..
else
использовать другой механизм.

← →
Игорь Шевченко © (2009-06-04 12:19) [45]

vuk © (04.06.09 12:16) [43]

На прорисовке после того, как установлен Parent и Frame сделан видимым.
(Это я смотрю по логам своего перехватчика, где больше вызовов API-функций)

← →
vuk © (2009-06-04 12:27) [46]

Ну... Я так думаю, что если смотреть количество вызовов API функций, то это не совсем тот показатель. Тут надо именно время смотреть (да хоть GetTickCount-ом), ведь, например, при создании экземпляров и обращения к менеджеру памяти происходят, и копание в RTTI, а там не сильно много API вызовов будет.

← →
Игорь Шевченко © (2009-06-04 12:30) [47]

vuk © (04.06.09 12:27) [46]

> Тут надо именно время смотреть (да хоть GetTickCount-ом),
>

Им и смотрю. Напротив каждого вызова API в логе как раз стоит значение GetTickCount

Больше всего времени уходит на действия от момента готового по размерам и видимости фрейма без парента до момента, когда установлен парент, позиция и видимость фрейма.

← →
vuk © (2009-06-04 12:39) [48]

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

← →
Игорь Шевченко © (2009-06-04 12:42) [49]

vuk © (04.06.09 12:39) [48]

Если бы я нашел наследник TGraphicControl, который умеет выделять свой текст мышкой, я бы, например, заменил бы им Edit"ы...Пока не искал :)

← →
vuk © (2009-06-04 12:46) [50]

В гридах просто - в момент входа в режим редактирования создается InplaceEditor по размерам ячейки и все дела. Можно так же сделать.

← →
oxffff © (2009-06-04 12:47) [51]

> Игорь Шевченко © (04.06.09 12:17) [44]
> oxffff © (04.06.09 12:00) [41]
>
> Я могу еще раз повторить - теория мертва без практики.
>
>
> > От куда вы сделали вывод, что я забыл про Perform?
>
>
> Из приведенного кода TWinControl.DefaultHandler - вызовы
> Perform к нему не относятся.
>

Как это не относятся?

Вы про это знаете?
Perform->WndProc->Inherited WndProc->Dispatch->DefaultHandler

← →
Игорь Шевченко © (2009-06-04 12:52) [52]

> Dispatch->DefaultHandler

да ну ?

procedure TObject.Dispatch(var Message);
asm
PUSH ESI
MOV SI,[EDX]
OR SI,SI
JE @@default
CMP SI,0C000H
JAE @@default
PUSH EAX
MOV EAX,[EAX]
CALL GetDynaMethod
POP EAX
JE @@default
MOV ECX,ESI
POP ESI
JMP ECX

@@default:
POP ESI
MOV ECX,[EAX]
JMP DWORD PTR [ECX] + VMTOFFSET TObject.DefaultHandler
end;

← →
oxffff © (2009-06-04 12:59) [53]

>
> Это корректное утверждение.
>
> В коде для наследников TWinControl встречаются фразы if
> HandleAllocated then ...
>
> В коде для наследников TControl, соответственно
> if csLoading in ComponentState then (как вариант if csReading)
> then
>
> ..
> else
> использовать другой механизм.

Давайте еще раз.

> Игорь Шевченко © (03.06.09 16:31)
> Сообщениями они не обмениваются только в случае csLoading
> in ComponentState или если не создан Handle окна для наследников
> TWinControl.

Вы обобщаете для всех контролов VCL. Это не корректно.
Никто не мешает производить обмен CM_ сообщениями между контролами.
Для многих(большинства) контролов проверки csLoading нет.
А вот на упомянутый вами HandleAllocated есть у некоторых есть.

Так вот я вам и предлагаю воспользоваться установкой FHandle в 0.

← →
oxffff © (2009-06-04 13:02) [54]

> Игорь Шевченко © (04.06.09 12:52) [52]
>
> > Dispatch->DefaultHandler
>
>
> да ну ?

Что да ну?

Вызов Dispatch->DefaultHandler происходит когда нет соответствующего динамического метода.
А обработка Twincontrol.DefaultHandler происходит очень часто .
Смотрите

procedure TWinControl.DefaultHandler(var Message);
begin
...

> Result := CallWindowProc(FDefWndProc, FHandle,
> Msg, WParam, LParam);

← →
Игорь Шевченко © (2009-06-04 13:09) [55]

oxffff © (04.06.09 12:59) [53]

Еще раз - теория нифига не стоит без практики.

> Вызов Dispatch->DefaultHandler происходит когда нет соответствующего
> динамического метода.
> А обработка Twincontrol.DefaultHandler происходит очень
> часто .

Если не затруднит - значение частоты в студию. Конкретно - сколько вызовов TControl.WindowProc заканчиваются CallWindowProc

← →
oxffff © (2009-06-04 13:25) [56]

> Игорь Шевченко © (04.06.09 13:09) [55]
> oxffff © (04.06.09 12:59) [53]
>
> Еще раз - теория нифига не стоит без практики.

Моей практике достаточно для решения задач как простых так и сложных.
Писать за вас код я не хочу.
К тому же вами не озвучены устанавливаемые свойства и используемые контролы.

> Если не затруднит - значение частоты в студию. Конкретно
> - сколько вызовов TControl.WindowProc заканчиваются CallWindowProc

Вы установите Tedit на пустую форму.
И установите Бряк на Result := CallWindowProc(FDefWndProc, FHandle,
Вы будете там постоянно.

← →
Игорь Шевченко © (2009-06-04 13:30) [57]

oxffff © (04.06.09 13:25) [56]

> Моей практике достаточно для решения задач как простых так
> и сложных.

Моей тоже. На сем дискуссию конкретно с тобой считаю завершенной.

из поста [37]:
"В принципе, я задавал вопрос на тему, может, существует какая-то неизвестная мне гайка/набор гаек, которые позволят безболезненно сделать аналог BeginUpdate/EndUpdate.

Если не существует, ну что же - будем с тормозами жить :)"

← →
oxffff © (2009-06-04 13:32) [58]

> Игорь Шевченко © (04.06.09 13:30) [57]

Могу только добавить.
Надеюсь меня не забаните.

← →
asails (2009-06-04 18:57) [59]

> Игорь Шевченко © (03.06.09 23:58) [26]
> тимохов © (03.06.09 23:45) [24]
>
> Почему не хочу динамически - потому что нарисовав фрейм
> я сгруппировал данные логически. Причем, с одной точки зрения
> логическая группировка одна, с другой - другая, с третьей
> - третья. Я ее (группировку) вижу и могу показать другому,
> дескать, устраивает тебя так или ты хочешь иначе сгруппировать
> ? Если иначе - нарисовал другой фрейм и все радостно.
>
> Делать такие вещи в динамике мне представляется недостаточно
> наглядным :)

Игорь, я все-ж предлагаю вернуться к рантайм. Если это решает проблемы быстродействия, то проблему наглядности решить проще (имхо).
Например, создавать контролы динамически, но используя заранее заготовленые фреймы, как шаблоны. Тогда, вместо того, чтобы скрывать часть уже существующих контролов, а другие двигать вверх (а тут я так понял и основные тормоза), можно просто игнорировать не актуальные и создавать/отображать только нужные. Причем, заданная заранее логическая группировка сохраниться.

Ну, это если я правильно понял задачу :)

← →
Игорь Шевченко © (2009-06-04 19:20) [60]

asails (04.06.09 18:57) [59]

Спасибо, но воспользовавшись советами в том числе из этой ветки, я добился того, что большая картинка стала рисоваться вполне приемлемое время, вместо 5..10 секунд 0,5..1,5.
Небольшая, соответственно, еще быстрее :)

Я установил у своих фреймов свойство Visible в false при создании и устанавливал его в true только когда фрейм был полностью подогнан под текущие данные.
Я стал присваивать свойство Parent фрейму только когда фрейм был полностью подогнан под текущие данные.

Я поставил у всех TLabel AutoSize в false, исключив лишние вызовы DrawText.
Я несколько изменил реакцию на изменение части свойств у своих наследников TEdit, исключив часть потока сообщений.

Если найду/придумаю наследник TGraphicControl, который позволяет выделять текст мышью, откажусь от наследников TEdit (в большинстве случаев).

← →
pasha_golub © (2009-06-05 15:06) [61]

Я тут выпал немного из темы. Андрюха Мистик предлагал в DFM сгружать\загружать. А почему бы просто в Stream не сгружать\менять\загружать? Всяко быстрей.

← →
pasha_golub © (2009-06-05 15:09) [62]

var SS: TStringStream;
MS: TMemoryStream;
S: striing;
begin

S := "object KakoyNibud: TChegoNibud"#13#10+
....
"end;"

SS := TStringStream.Create(S);
try
MS := TMemoryStream.Create;
try
ObjectTextToBinary(SS,MS);
MS.Position := 0;
MS.ReadComponent(AComponent);
finally
MS.Free;
end;
finally
SS.Free;
end;
end;

← →
Игорь Шевченко © (2009-06-05 15:26) [63]

pasha_golub © (05.06.09 15:06) [61]

И чего будет ?

← →
pasha_golub © (2009-06-05 16:44) [64]

> Игорь Шевченко © (05.06.09 15:26) [63]
>
> И чего будет ?

Ну суть предложения сводилась, к изменению свойств в DFM, а потом загрузке (если я правильно понял)

Выгрузили в стрим, поменяли чего хотели, загрузили из стрима. не?

← →
Игорь Шевченко © (2009-06-05 17:42) [65]

pasha_golub © (05.06.09 16:44) [64]

> Ну суть предложения сводилась, к изменению свойств в DFM,
> а потом загрузке (если я правильно понял)

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

Собственно, в 5-то раз отображение я ускорил, так что пока вроде терпимо.

Попользовался триальной версией AQTime - вещь!

← →
pasha_golub © (2009-06-05 18:57) [66]

> Попользовался триальной версией AQTime - вещь!

Вещь. Согласен.

> Нет, суть предложения сводилась к формированию собственного
> DFM и ее загрузки.

Формировать-то действительно громоздко. А что если загрузить, дфм, не отображая, внести изменения и применить к объекту.

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

← →
Игорь Шевченко © (2009-06-05 19:05) [67]

pasha_golub © (05.06.09 18:57) [66]

> А что если загрузить, дфм, не отображая, внести изменения
> и применить к объекту.

к объекту чего ? У меня объект в данном случае - это TFrame, грузится из DFM, не отображается, к нему применяются всякие мамбл-ванго, потом он отображается.

Беда в том, что фреймов может быть дофига :)

← →
pasha_golub © (2009-06-05 19:07) [68]

Ну нет, так нет. Зато засветился в общении с умными людьми. :))

← →
int64 (2009-06-06 14:37) [69]

Игорь, не пробывали что-то типа этого:

TWinControlHelper = class helper for TWinControl public procedure ClearPerformingShowingChanged; procedure SetPerformingShowingChanged; end; TForm3 = class(TForm) procedure FormCreate(Sender: TObject); procedure FormShow(Sender: TObject); end; var Form3: TForm3; implementation {$R *.dfm} const // hack to temporarily store state in ControlStyle csPerformingShowingChanged: Cardinal = 1 shl (Byte(csAlignWithMargins) + 1); procedure TForm3.FormCreate(Sender: TObject); begin SetPerformingShowingChanged; end; procedure TForm3.FormShow(Sender: TObject); begin ClearPerformingShowingChanged; UpdateControlState; end; procedure TWinControlHelper.ClearPerformingShowingChanged; var I: Integer; begin ControlStyle := TControlStyle(Cardinal(ControlStyle) and Cardinal(not csPerformingShowingChanged)); for I := 0 to ControlCount - 1 do if Controls[I] is TWinControl then TWinControl(Controls[I]).ClearPerformingShowingChanged; end; procedure TWinControlHelper.SetPerformingShowingChanged; var I: Integer; begin ControlStyle := TControlStyle(Cardinal(ControlStyle) or csPerformingShowingChanged); for I := 0 to ControlCount - 1 do if Controls[I] is TWinControl then TWinControl(Controls[I]).SetPerformingShowingChanged; end;

← →
int64 (2009-06-06 15:56) [70]

Помоему,
ClearPerformingShowingChanged;
UpdateControlState;
лишние.

Ну, вообщем, идея такая: чтоб на время "загрузки" для любого контрола не только Visible = False, но еще и PerformingShowingChanged возвращала True.

← →
Игорь Шевченко © (2009-06-06 23:50) [71]

int64 (06.06.09 15:56) [70]

Спасибо за идею. Собственно, CM_SHOWINGCHANGED не вызывается, а основные тормоза, как выяснилось, происходят из-за массового использования TWinControl. Если я найду TgraphicControl, умеющий выделять мышью текст, то откажусь от наследников TEdit, а если не найду - так вроде и без того ускорил, пока терпимо :)

> роисходят из-за массового использования TWinControl

собсно я тебе где-то раньше это и хотел сказать - беда в большом количестве компонентов (

Игорь, твой случай - рисовать самому. Т.е. что-то типа грида своего нарисовать. долго, муторно, зато перевариваться будет много информации.

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

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

proc SomeProc; asm jmp @CommonOverrideImplementation end;

SPeller © (08.06.09 12:05) [73]

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

Не понял мысли, не затруднит пояснить на пальцах ?

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

Не могу сказать какие методы нужно перекрывать и что в них делать, просто описал путь, которым можно сделать динамику, оставив при этом визуальную правку формочек. Если, конечно, я что-то не упустил из описания задачи.

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

SPeller © (08.06.09 12:35) [76]

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

Как применить твою мысль к этому ? :)

А можно перекомпилить системные исходники и сунуть FComponentState в protected :)

Я уже понял что мысль моя первоначальная оказалась оторвана от действительности )

Кстати, я когда баловался с перекомпиляцией Variants для kol обнаружил что компилятор ругается на Unit variants was compiled with different version of kol.pas только тогда когда в этом kol.pas затрагиваешь функцию, вызов которой присутствует в variants. Думаю что по аналогии можно перенести и поле класса, и не тронуть при этом никого из существующих модулей.

> А можно перекомпилить системные исходники и сунуть FComponentState
> в protected :)

нельзя, они в BPL :)

ну это уже засада )

Такой вопрос - зачем вам TEdit и откуда он рожает кучу сообщений?

SPeller © (08.06.09 13:52) [84]

TEdit мне нужен, чтобы из него текст мышкой/клавиатурой выбирать, и вставлять в Clipboard.
Сообщений он рождает по своей природе - практически любой наследник TWinControl порождает больше сообщений, чем наследник TGraphicControl, не говоря о ресурсах :)

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

> Можно в этом случае показывать графические контролы, а один
> единственный эдит держать скрытым и показывать при клике
> по нужному полю настраивая размеры перед показом

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

Ну... Если бы у меня возникла такая задачка, я бы, наверное, применил QuantumGrid и его CardView. То есть, на каждом фрейме - всего один грид c CardView и потом опять плодить кучу фреймов.
Ну, или, как вариант, их же VerticalGrid...

> Игорь Шевченко © (09.06.09 12:00) [87]
>
> > Можно в этом случае показывать графические контролы, а
> один
> > единственный эдит держать скрытым и показывать при клике
>
> > по нужному полю настраивая размеры перед показом
>
>
> Думал на эту тему (тем более, есть опыт). Здорово усложняется
> поведение, еще не до конца понятно, стоит ли овчинка выделки.
> Пока лучшим вариантом является, на мой взгляд, неспешный
> поиск TGraphicControl, который умеет текст мышью выделять
> :)

TGraphicControl получает все сообщения от WinControl.
Поэтому от TWincontol вы ни как не избавитесь.

Сообщения от мыши он получает здесь

function TWinControl.IsControlMouseMsg(var Message: TWMMouse): Boolean;

Control := ControlAtPos(SmallPointToPoint(Message.Pos), False);
Result := False;
if Control <> nil then
begin
P.X := Message.XPos - Control.Left;
P.Y := Message.YPos - Control.Top;
Message.Result := Control.Perform(Message.Msg, Message.Keys, Longint(PointToSmallPoint(P)));
Result := True;

А вот сообщения от клавиатуры до него не доходят. Read Help.

TGraphicControl is the base class for all lightweight controls.

Unit

Controls

Description

TGraphicControl supports simple lightweight controls that do not need the ability to accept keyboard input or contain other controls.

Поэтому наблюдая за развитием темы со стороны мне не понятно как вы собираетесь и я решил поделиться своим IMHO

> Игорь Шевченко © (08.06.09 13:54) [85]
> TEdit мне нужен, чтобы из него текст мышкой/клавиатурой
> выбирать, и вставлять в Clipboard

Если мышкой возможно, то клавиатура не предусмотрена.

P.S.

Очень надеюсь обойтись без вашего бана.

> очень простой задачи

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

> Игорь Шевченко © (09.06.09 16:12) [91]

Алгоритм высчитывания длины текста в определенном шрифте есть в интернете.
Может стоить обратиться к google?
Например начать с GetTextExtentPoint32.

← →
ANB (2009-06-09 18:03) [93]

> Не думал что Мастера Delphi настолько суровы, что готовы
> отказываться от решения очень простой задачи.

Вопрос - а надо ли ее решать таким способом ?

oxffff © (09.06.09 17:21) [92]

> Алгоритм высчитывания длины текста в определенном шрифте
> есть в интернете.

Это и есть решение МОЕЙ задачи ?

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

> Игорь Шевченко © (09.06.09 18:29) [94]

Для начала прошу ответить на мой вопрос из [89] как TGraphicControl будет принимать ввод с клавиатуры?

oxffff © (09.06.09 20:43) [95]

Ты где-нибудь в моих постах видел упоминание о клавиатуре ? Напротив, я писал о выделении текста мышью.

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

> Это и есть решение МОЕЙ задачи ?

Боюсь Ваша личная самая самая самая главная задача нерешаема.

> Игорь Шевченко © (08.06.09 13:54) [85]
> SPeller © (08.06.09 13:52) [84]
>
> TEdit мне нужен, чтобы из него текст мышкой/клавиатурой
> выбирать, и вставлять в Clipboard.

И поскольку вы далее в качестве дальнейших шагов рассматриваете замену на TGraphicControl вместо TEdit.
Поэтому у меня(и не только у меня) возникает вопрос как быть в копированием в буфер с клавиатуры. Разве он не возникнет, как вы считаете?

> Я не понимаю, чего ты так возбуждаешься ?

:).

Спасибо конечно. Мне бухгалтерии на работе хватает.
И компилятора по вечерам. Так что я сейчас спокоен как танк.

oxffff © (09.06.09 21:53) [99]

Мне, собственно, тоже хватает других задач. Если ты внимательно читал, то я спрашивал про некую общую гайку, которая может позволить, а не про замену компонентов, мамбл-ванго с WndProc и прочие, требующие больших дополнительных усилий, действия. Если простой гайки нет - дополнительные телодвижения делаться, скорее всего, не будут, кто бы тут не возбуждался насчет суровых мастеров дельфи.

> Игорь Шевченко © (09.06.09 22:43) [100]

А если использовать TLabel для показа текста. А если по нему клинкнуть (провести над ним мышью или как удобно). Создавать на его месте TEdit.
Есть затем ткнуть во второй Label, то Edit на месте первого удаляется, а на месте второго появляется.
Для того, чтобы было понятно, что по нему можно ткнуть - изменить форму курсора мыши для labelов.

И еще мне немного помогло в аналогичной ситуации скрыть scrollbox на время обновления.

сделать для формы (фрейма, WinControl) аналог Begin/EndUpdatе Найти похожие ветки