Gawd, tracing what happens when you resize a form is MIND NUMBING stuff.
Anyhow, the chain of events near as I can tell:
you resize the form
windows sends WM_SIZE to the form, form enters WMSize
during handling of WM_SIZE the align code resizes the form
WMSize called recursively to handle new aligned size
various processing
WMSize exits...
...back to (eventually) WMSize
WMSize exits again
controls get repositioned based on new size
Now I could be completely wrong, but it looks like the re-entrance to WMSize
is causing at least part of the problem. There are various flags and
counters to prevent controls getting repositioned before the size/align
sequence is completed, but I think there's a locking problem where some
internal rect is not updated correctly before repositioning the controls.
This is a bug, and frankly it's not one I'd like to tackle with my limited
knowledge of VCL internals. There's too much going on behind the scenes in
response to WM_SIZE for me to make sense of in less than a couple of days of
study. Just finding the sequence above took almost an hour, and that was
after I coerced BCB into letting me call some 'private' member functions :>
Call me crazy, but shouldn't the size limitations (again, alignment and
constraints) be applied in response to WM_SIZING? That way you only get a
WM_SIZE message with a valid window size that has already had the size
limits imposed. No more changing size half way through handling WM_SIZE,
which should eliminate this bug.
But then WM_SIZING didn't appear until NT4, so I guess it wouldn't work on
NT3.51... anyone still writing for that? <G>
--
Corey Murtagh
The Electric Monk
"Quidquid latine dictum sit, altum viditur!"
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED]
with body of "unsubscribe delphi"
