There seems to be a lot of disinformation/confusion about the real-time size event floating around, so let me clear this up a bit.
How it works in Windows (and also in OSX):
Windows uses callbacks to dispatch events. The main event loop is only there to dispatch events and usually not used to handle the events directly. This is generally not a problem for the PB event-loop system because you can generally also handle the events in the main loop. However, the #WM_SIZE and #WM_MOVE Windows events (and some others too) are different: Once the user starts draging the window edge to do a resize,
control does not return to the main loop until the user finishes draging. Instead, Windows repeatedly calls the callback to inform about the ongoing sizing activity. The main loop only gets control at the end of the sizing.
How it worked in PB before 5.30:
Since there was no BindEvent() in PB before 5.20, this behavior presented a real problem, because there was no way to react to sizing events while the window edge was dragged with PB only means. You needed a Window callback to do it. To solve this problem, I actually did a little bit of reverse-engineering to figure out which messages Windows sends during the resizing and re-implemented my own window resizing code that mimics the Windows behavior, but gives control back to the event loop. This way, no OS specific window callback was needed to properly handle size events.
I did this way back when Windows XP was new and shiny. Since then, new Windows versions have come out which implemented their Sizing-Code differently and it is hard to keep imitating it correctly. You can see that there are differences with the PB version even since Windows Vista, because PB windows react differently to the "drag a Window to the edge of the screen" resizing functionality that was introduced there. Furthermore, since Windows 7 or 8, there are these flickering issues which are hard to overcome with our custom sizing hack. I do not have to tell you that trying to reverse-engineer such code is not a good idea in the long term. This is why we were never really happy with this solution, but before 5.20, there was simply no other way. The "flickering" issue describe in the 5.30 announcement is only the most visible result of a generally bad solution.
Why we changed it in 5.30:
I already wrote why the solution is bad. Since release 5.20 we now have the BindEvent() command which is a PB only and cross-platform method to register an event callback. This is why we removed the above hack in favor of the native solutions. This way, PB created windows once again act 100% like other Windows in terms of resiting behavior and the solution is future proof.
What changed:
All you have to do is to move your resize code from the main loop into a procedure and call BindEvent() for it. You then once again get
all events like you did before. Nothing has been removed. Only the method of event delivery has changed.
> But the big advantage of the event driven system gets lost, those events fire in the middle of my other code and I have to secure anything.
This not true: The BindEvent procedures are only called while you are inside of a WaitWindowEvent() or WindowEvent() call. They are sometimes also called from functions that change the GUI (if this change directly generates an event). However, they are never called "in the middle of your code".
There is no multi-threading going on here, so there is no need to secure anything in the event callbacks.
PureBasic 5.30 (beta) est disponible sur votre compte
Répondre avec citation
Partager