[lazarus] Win32: moving and message handling

[Karl Brandt]

Micha Nelissen wrote:
> Hi,
> 
> I still have to object again the latest patch for WM_MOVE handling, the 
> previous one was better. That is because the internal variables haven't 
> been updated when WM_MOVE is sent, only after it has been processed they 
> are updated. So when GetWindowRect is called it retrieves the wrong 
> values. So use the information in the LParam at least:

I'd like to thank you by the progresses you made in LCL recently, but i 
think in this case you are wrong.
First i must say that this aproach isn't mine: it was there for a long 
time and Martin Smat excluded it 3 months ago, causing that strange 
effects in moving/resizing
The GetWindowRect is a windows API function and retrieves the actual 
position of the window (is not related to LCL).

> XPos := LoWord(LParam);
> YPos := HiWord(LParam);

These values are the position of clientarea wich are something bigger 
than windowarea
Try the following:
change source to
XPos := LoWord(LParam);
YPos := HiWord(LParam);
make a simple form program with top,left=(0,0);
make breakpoints in WM_MOVE, WMMove;
the prog will stop after the sizing proccess (WindowMove fires WM_Move);
you will see that XPos and YPos are something bigger than 0
in WMMove, LCL will think that you moved the form (remenber left,top in 
LCL are (0,0) and until now you haven't moved anything) and will request 
the interface to change the position of form based on the passed values

This will result in another position diferent than (0,0) in the first 
time the form is show

> (Maybe compensate for client rect ourselves, but certainly don't use the 
> GetWindowRect / GetClientRect functions). This also explains the weird 
> behaviour of maximizing: The form stays the same size because 
> GetClientRect returns the previous client size, not the current one.

GetClientRect is a windows API function that retrieves the actual 
position/size

You can take a look in the thread Behavior of LCL Client Area (was: 
win32 development) in mailing list archive (2003) to understand some 
issues with VCL/LCL, win32/XWindow sizing.

karl