The problem I have is that with Xojo 2019.1 whenever there is in an event a Canvas.Refresh, it does not trigger the Paint immediately, but reads all the subsequent instructions, and when that event is done, then it triggers the Paint event. For example, I have somewhere in my MouseDown event a Canvas.Refresh instruction. After this follow other instructions. These instructions are all executed before the Canvas.Refresh is triggered. This causes the trouble to my project.
This wasn’t the case in previous releases, where a refresh was triggered immediately at the instruction. Is this supposed to be so or is it a bug?
Im not sure where the change was actually made, but I dont think its in Xojo but rather in MacOS. They dont want you to force screen redraws anymore at all. All screen refreshing is done after you return to the event loop, or whatever the modern equivalent is.
You have to break up your drawing with timers. Your code has to do its first bit of drawing, then start a Timer and return. The Timer can do the next part of the drawing and return. Then the canvas will update after each one.
I still think it should read the instructions of the Paint event directly after a refresh, even though the refresh of the screen happens at the end of it all.
@Norman Palardy Thank you for your help, but I don’t understand Sam’s code and how to use it, so that the code in the Paint event is executed directly after a Refresh.
But I discovered that App.DoEvents solves my problem. If I place it directly after Canvas.Refresh, it works. Is it a good idea to use App.DoEvents?
According to almost everyone… DOEVENTS IS EVIL and should never be used…
I do not know if it does something different than the same command from VB6/Net … but there it simply flushed the message queue (same as what happens at the end of a run cycle), and if so, I fail to see the “evil” in that
In Xojo, DoEvents RUNS the event loop. So if you’re in the middle of an event (which you almost always are) and call DoEvents, it will run the event loop again while you are already in it. Bad things may transpire.
[quote=432140:@Payam Arzani]@Norman Palardy Thank you for your help, but I don’t understand Sam’s code and how to use it, so that the code in the Paint event is executed directly after a Refresh.
But I discovered that App.DoEvents solves my problem. If I place it directly after Canvas.Refresh, it works. Is it a good idea to use App.DoEvents?
[/quote]
No - avoid app.doevents like the plague
There are very very very limited use cases where it wont cause problems in a GUI app
This is not one
[quote=432141:@Dave S]According to almost everyone… DOEVENTS IS EVIL and should never be used…
I do not know if it does something different than the same command from VB6/Net … but there it simply flushed the message queue (same as what happens at the end of a run cycle), and if so, I fail to see the “evil” in that[/quote]
It unfortunately has the same name but it does NOT do the same thing as DoEvents from VB
Avoid it is the best advice you can remember about it
Chances are that youre going to have to rethink how youre doing things.
If you fight the system, you will lose; maybe not today, but often when you really dont have time to deal with it. If you dont keep up with rabid pace of alterations made to the macOS; youll lose…
It sounds to me like youre trying to do animation. Theres a bunch of kits out there for doing this, but in principle you may want to use a timer (a period of 16, gives you 60 fps) and design your animation to be time based. When the timer fires, it calls a method to update your values. Use time (ticks or microseconds) to update the values based upon the time into the animation, never update based upon how many frames have passed. Once youve updated your values, you then invalidate the canvas. Which in turn will call the paint event on the next cycle. In the paint event you use those values to draw your animation.
I managed to adapt the code to these changes. It now works with the 2019 release. But I still want to use the 2017 release. So my question is when will Apple force those changes, so that the Xojo 2017 will become useless on new macOS?
I have seen the same app created with one version of Xojo behave slightly different on Mac 10.12.x, 10.13.x and 10.14.x (some redraw differences). You will need to test with different macOS version to see if your app behaves as you want or not (at least for the main features).
