I am not drawing any conclusions yet, I am just saying the current approach is not working OK.

I see. I am now working on a function to convert those to the wanted coordinates.

Regards,

Micha.

The maximizing should now be better.

Mattias

Micha Nelissen wrote

(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.

I have some binaries where maximizing works properly with calling GetWindowRect / GetClientRect functions in WM_SIZE and WM_MOVE. The problem is in another place.
In really, GetClientRect in WM_SIZE isn't necessary since the LoWord/HiWord(LParam) already give the client sizes, but changing this doesn't fix maximizing.

Currently LM_WINDOWPOSCHANGED does nothing. All is done with WMSize and WMMove.
The order of the messages is : WM_WINDOWPOSCHANGED > WM_MOVE and/or WM_SIZE

karl

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:

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

(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.

About message handling: maybe it would be better the always first pass the message into the LCL, then if the LCL doesn't handle, let it pass through and call the default window proc in DefaultHandler. The problem is that now the LCL first receives WM_MOVE and then WM_WINDOWPOSCHANGED because internally windows calls WM_MOVE inside handling the WM_WINDOWPOSCHANGED.

Regards,

Micha.

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

Maybe this had to do with your GetWindowRelativePosition.

Sorry if i missed something,but with these changes TLMSize.SizeType is always Size_SourceIsInterface. How can the form update the FWindowState?

Size_SourceIsInterface is now a flag added to WParam. The other states are not yet implemented in the gtk-interface and the LCL does not yet react properly to the states.

Mattias

Now the maximizing works, but some controls are not show. See examples.

Sorry if i missed something,but with these changes TLMSize.SizeType is always Size_SourceIsInterface. How can the form update the FWindowState?

karl