Resizing in win32

[big_M]

When I resize a form in qt5/gtk2 the onresize event gets triggered constantly as soon as I start resizing a window, but not so in win32 where it only fires after the resizing is done.

Is there any way to change this?

[balazsszekely]

When I resize a form in qt5/gtk2 the onresize event gets triggered constantly as soon as I start resizing a window, but not so in win32 where it only fires after the resizing is done.

Is there any way to change this?

In win32 you have to catch the WM_ENTERSIZEMOVE and WM_EXITSIZEMOVE messages.

[big_M]

Oh, I see. Thx!

[nanobit]

but not so in win32 where it only fires after the resizing is done.

You use a Lazarus version which does not work.
Older versions (like my 2.0.x and older) and possibly the latest version fire onResize like you want.

[big_M]

In win32 you have to catch the WM_ENTERSIZEMOVE and WM_EXITSIZEMOVE messages.

Hm, I must admit this is currently a bit beyond my abilities. I have no clue about messages.

You use a Lazarus version which does not work.
Older versions (like my 2.0.x and older) and possibly the latest version fire onResize like you want.

Interessting. Is this a known behaviour/bug? I tried 2.2.2 and 2.2.4 on two different machines with Windows 10, they both behave the same

[balazsszekely]

Hm, I must admit this is currently a bit beyond my abilities. I have no clue about messages.

https://forum.lazarus.freepascal.org/index.php/topic,41843.msg291170.html#msg291170

[nanobit]

Is this a known behaviour/bug? I tried 2.2.2 and 2.2.4 on two different machines with Windows 10, they both behave the same

I use only the older LCL which has a simpler concept.
For all newer versions there is a report. It may help you to continue, but this change has also some sideeffects (on operations which utilize the non-message queues (threadQueue, asyncCall)).

[big_M]

https://forum.lazarus.freepascal.org/index.php/topic,41843.msg291170.html#msg291170

Thank you for the example, I will give it a try.

I use only the older LCL which has a simpler concept.
For all newer versions there is a report. It may help you to continue, but this change has also some sideeffects (on operations which utilize the non-message queues (threadQueue, asyncCall)).

That's good to know. I always use OnResize to update while dragging, eventhough that seems to be suboptimal. Let's see, I'm curious to see the difference. At least OnResize is system agnostic.

Btw, are there similar messages on linux? Because qt5 scales without flicker with OnResize, but gtk2 is not great...

[big_M]

Ok, so for updates while dragging I actually need WM_SIZING. WM_ENTERSIZEMOVE and WM_EXITSIZEMOVE just get sent once (makes sense), so the behaviour is the same as with OnResize currently. It renders okey, but from memory, I wouldn't say it renders any better then using OnResize (maynard philbrook's comment on the posted report implied it would). But I would need to have a side by side comparison to confirm that.

[balazsszekely]

@ big_M

Ok, so for updates while dragging I actually need WM_SIZING.

Yes you're right, I misunderstood your question, you indeed need WM_SIZING. Sorry for that!

It renders okey, but from memory, I wouldn't say it renders any better then using OnResize

As @nanobit already mentioned the resizing mechanism is broken in the latest stable release Lazarus 2.2.4, however it works fine with Lazarus trunk/main(just tested). So if you use 2.2.4 you need to catch WM_SIZING, in other version you can use the OnResize event.

PS: Current bug aside,  in my experience combining WM_SIZING with WM_ENTERSIZEMOVE/WM_EXITSIZEMOVE gives you a much finer control, I prefer catching those messages, over OnResize in windows.

[big_M]

Yes you're right, I misunderstood your question, you indeed need WM_SIZING. Sorry for that!

No problem at all. Thanks for your help!

PS: Current bug aside,  in my experience combining WM_SIZING with WM_ENTERSIZEMOVE/WM_EXITSIZEMOVE gives you a much finer control, I prefer catching those messages, over OnResize in windows.

Yes, I see. It can certainly be helpflull in some situations