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

← →
Игорь Шевченко © (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.

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 :)

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

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