EventLoop not allways executed on Windows and MacOS

[Niffo]

Unlike on Linux, Purebasic does not enter in his EventLoop on Windows and MacOS when a Window is moved or simply when a menu is opened (!). So any form of timing operation is impossible and even the new "WindowTimers" of PB4.40 does not trigger in these cases.
Any chance of a change of that ?

[rsts]

From my own experience, it's preferable the way it is, unless the move behavior was some sort of option.

cheers

[Kaeru Gaman]

I don't know what is the reason for it, but it "always" has been this way.
a WindowedScreen freezes when you move the Window or open the Menu.
the only thing you can do is to handle your timing in a way that pays attention to this behaviour.

it really would be interesting to know what the reason is,
and it would be nice if that behaviour could be changed.


@rsts

it's preferable the way it is

ermn... nope?

unless the move behavior was some sort of option

hu? don't understand what you mean?

[Offin]

My application must send continuously an udp streaming, and i would like to use the PopupMenu item.
Right now, i have no choice to forget the PopupMenu and to find a workaround.
Just to tell you that PopupMenu which keeps EventLoop access would be great also for me.

[c4s]

You mean the eventloop is blocked while the window is moved or an popup window is opened? That is as Kaeru Gaman already said completely normal.
You should use a thread to send you udp stuff because it's working simultaneously to the eventloop so it won't be blocked.

[Niffo]

Threads should be the solution, but its use in PB seems to be very "delicate" and causes many "IMA" (particularly on MacOS ? ...)

[Kaeru Gaman]

not the use of threads causes the IMA, but the incorrect coding concerning Stack, Heaps shared Variables, Strings, etc.
threads are safe if you halfways know what you do.

[HeX0R]

See -here-, i also think this is a bad behaviour of PB.
If the events just freezing, this wouldn't be that bad (well bad enough though), but they've got lost...