Continuing with the progressbar example till it works :). Attached is a fix to correctly…
Show quoted text 12 lines
Mattias Gaertner wrote:
> On Wed, 25 Jun 2003 20:36:54 +0200
>> The 'Smooth' property does not work yet, it needs to be set when the
>> control is created. Apparantly, you cannot set it later on, using
>> SetWindowLong, as the code now tries to. Can a window recreate be
>> forced within handling the LM_SETPROPERTIES message handler?
>
> Hmm. As far as I can see, LM_SETPROPERTIES is only called in
> ApplyChanges, and this is now only called after Loading, on
> initializing the window and on property change.
FYI: ApplyChanges is also called when Min,Max,Smooth,... are set. Example:
I ment this with: "on property change"
Show quoted text 22 lines
procedure TProgressBar.SetMax(Value: Integer);
begin
if FMax Value then
begin
FMax := Value;
ApplyChanges;
end;
end;
> So, yes, you can recreate the Handle. But make sure, you only do it,
> when properties has really changed. Otherwise InitializeWnd will loop.
Does this mean I have to detect the case that LM_SETPROPERTIES is called
from InitializeWnd separately?
Another Q: would it be possible to pass extra information about what has
changed? For LM_SETPROPERTIES, Data is unused, maybe we can specify
LMS_PROGRESSBAR_MIN, LMS_PROGRESSBAR_SMOOTH, etc... ? Other controls could
have other flags like LMS_SCROLLBAR_RANGE. (LMS_SCROLLBAR_RANGE could have
the same value as LMS_PROGRESSBAR_MIN, it's a different control). Then we
won't have to check the complete current state of the object versus the
wanted state.
Yes we could. But the checks are needed anyway:
If during an update phase a property is changed from value A to value B and then back to A, the interface should not recreate the window. And there are some cases during events, when the LCL and the interface are not in sync. And most important: Ten complete checks are always cheaper than one redraw/recreate.
Mattias