Thread synchronization is blocket until window is moved or resized

[michalgw]

Thread synchronization is blocket until window is moved or resized. This only happens under windows-gdi. On linux-x11 it works fine.

Run test project and try to move or resize the window. Test project: http://sourceforge.net/p/fpgui/bugs/15/attachment/testsync.zip

[graemeg]

It's not a bug, you are simply doing a lot of things wrong in that test app.

1. Never use Sleep() inside a thread!
2. Never draw outside the OnPaint event. Increment the counter and call Invalidate. Then do the painting inside the the Form's OnPaint event handler.
3. You are not freeing the thread when the application eventually terminates.
4. Start the thread suspended, set all its properties, then in the Form's OnShow you start the thread. This gives the main form time to fully load and be ready.

Applying all these, then you will have a working application. I use threads all the time in my applications on Windows, Linux and FreeBSD. Threads work just for with fpGUI based applications.

What I'll do is commit a new demo showing threads in action - using the classic Delphi demo of comparing three sort algorithms - each running in a separate thread.

[michalgw]

Thank you for the advice, but it still does not work. http://pastebin.com/mfsx2H9Z

I am waiting for your working example of using threads.

[fredvs]

Hello.

I have try all the examples of michalgw with fpc 3.0.0. and fpGUI 1.4 maint with wine and Win10. It works perfect here.

I try changing: Synchronize(@DoSync); with Queue(@DoSync);

It works too.

Fre;D

[rchastain]

Tested on Linux with latest fpGUI source (develop branch). It works perfectly. I believe that this issue could be closed.

[michalgw]

As I wrote, the problem occurs on Windows. It worked fine on Linux.

[rchastain]

As I wrote, the problem occurs on Windows. It worked fine on Linux.

Ah, sorry. I will make a test on Windows ASAP.

[rchastain]

Compiled and tested the test program under Windows. Both versions (32-bit and 64-bit) work as expected for me.

Latest fpGUI, develop branch, FPC 3.2.0.

threadsynctest-binaries-windows.zip

[michalgw]

I just tested and the problem still persists (fpgui-develop and fpc-main). To reproduce the problem, run program and grab title bar of form - thread synchronization is suspended.

[fredvs]

Hello.

Could you give, please, a code-example to test the synchro (here I dont have problems with grabbing the title bar.) ? Thanks.

[michalgw]

Try examples I've attached earlier: http://sourceforge.net/p/fpgui/bugs/15/attachment/testsync.zip http://pastebin.com/mfsx2H9Z

[rchastain]

I just tested and the problem still persists (fpgui-develop and fpc-main). To reproduce the problem, run program and grab title bar of form - thread synchronization is suspended.

Indeed, I didn't try to grab the title bar. I will try tomorrow.

[fredvs]

Hello michalgw.

Tested your demo compiled with fpc 3.2.2. 64 bit and fpGUI last develop branch on Linux 64 bit. Tested also your demo compiled with fpc 3.2.2. 32 bit and fpGUI last develop branch on Windows 11/last update . The Linux demo works ok when grabbing the window too. The Windows demo works ok when grabbing on Linux via Wine and also on Windows 11/last update.

In attachment, the binary of your demo ( for Linux and Windows).
testsync_bin.zip

Do you have also problems with that binary?

[michalgw]

Yes, the problem occurs with that binary (tested on Windows 10). When I grab title bar and move window - the form stops blinking and counter is not incremented until mouse button is released.

[rchastain]

Yes, the problem occurs with that binary (tested on Windows 10). When I grab title bar and move window - the form stops blinking and counter is not incremented until mouse button is released.

Don't feel offended, but shall we really consider that as an issue?

[fredvs]

Ha, ok, I get it now.

Indeed, on Windows 11, the form stop blinking while the mouse button is pressed. This does not occur with Linux-wine ( but Linux-wine is the best Windows version ever ;-) )

[michalgw]

Don't feel offended, but shall we really consider that as an issue?

If you are using threads then definitely yes.

Ha, ok, I get it now.

I probably should have described the problem better at the beginning.

[fredvs]

Interesting is that using queue() instead of synchronize() (https://github.com/graemeg/fpGUI/issues/14#issuecomment-272724697) does not loose the sequence while moving the window (like synchronize() does).

You may try with the binary compiled with queue(): testsync_queue.zip

[michalgw]

But if you run the second example (http://pastebin.com/mfsx2H9Z) with changed synchronize to queue the window remains unresponsive to mouse and keyboard because windows messages are not processed.

[fredvs]

Yes, it is what I noted.

With synchronize, for example if you begin to move the window with number "10" a certain time, the window is not refreshed and when you release the button, the next number wil be "11".

But with queue, if you begin with number "10" and move the window a certain time, it is not refreshed too but when you release the button, the next number will not be "11" but the number inc during the moving.

[fredvs]

But if you run the second example (http://pastebin.com/mfsx2H9Z)

Sorry but for all your link to pastebin I get error connection and cannot test it.

[fredvs]

Just tested with a MSEgui app with thread on Windows 11 and there all ok when moving window.

Now where to look, both use Windows gdi32 interface...? Any idea is welcome.

[fredvs]

Re-hello.

But if you run the second example (http://pastebin.com/mfsx2H9Z)

You may use this issue and paste the zipped file, it is more easy for everybody.

[michalgw]

I suspect the main application loop and/or gdi window procedure.

I attach an example: onmove.zip

[fredvs]

Hum, without minimum sleep(1) I cannot close your example. Anyway, yes there is a problem when moving window and thread-synchronization.

Did you try to synchronize something inside the form, like a paintbox? (sorry to ask it but I dont have easy access to Windows).

Is synchro bad too?

The best is to try to isolate the problem, when it begins (on mousedown, mouseclick, when moving the form, etc...? )

Then check on the TForm.method with problem what it does and maybe compare with msegui.

[michalgw]

Indeed, this example with queue is not the best, because the return from CheckSynchronize may never happen - more queue items may arrive while the queue is being processed.

Using synchronize it works like the first project - it pauses synchronization on moving and resizing.

Does fpGUI have paintbox? I can not find...

You can try to add DebugLn to beginning of fpgWindowProc and dump the windows message to see what's going on while moving/resizing.

[graemeg]

I can have a look tomorrow evening, after work. The fpgWindowProc should already have debug code for OS event debugging - you just need to compile the framework with the correct Defines.

Clicking on the title bar will not (should not) trigger a OnMouseDown if I recall, because that's outside the bounds of the application window. When moving the window, that should send WindowMove OS events to the application event handler.

Let me see what I can find. Thank you all for your investigation so far - it is very handy, and should help with debugging.

[fredvs]

Does fpGUI have paintbox? I can not find...

You may try painting on the canvas of a TOtherwidget or TFPGPanel.

[fredvs]

Does fpGUI have paintbox? I can not find...

Or simply, with a TfpgPanel, change the color and caption via the thread-synchronize.

[michalgw]

I just tried with TfpgPanel but effect is the same.