In another thread, I was told that contrary to 32 bit, MouseDown, MouseDrag in a canvas, or PopupMenu prevented timers from firing.
That can be a big problem in some of my classes, so I wanted to make certain.
I created a small project with 2017R1.1 that contains a canvas, a multiple 1000 ms timer, and a TextArea to receive messages that I would have sent to System.Debuglog in 32 bit.
This archive contains both the project, and a 64 bit build for Windows.
To my great surprise after what I had read, it appears the timer fires happily through MouseDown and MouseDrag in the Canvas, as well as during the PopupMenu dropdown display.
Then I proceeded to macOS Sierra and 2017R1.1 with a 64 bit build of the same project. Same result.
That should be good news for whomever uses timers in 64 bit.
Now there’s a compelling reason to finally bite the bullet and upgrade from RS2012
I use 3 versions depending on the task - 2012r2.1, 2016r4, and 2017r3. We still have some old Max OS Carbon and Windows XP users, so that’s why 2012r2.1. For Linux before GTK-3 and Windows 7-10, we use 2016r4 for existing projects, and new development is using 2017r3.
This is working pretty well for the myriad of users we support.
I much prefer the RS IDE to Xojo, but I have some issues with UI processes like window-dragging interfering with timers, so maybe this will help.
Is this a 64 bit thing? Im pretty sure on the Mac at least that it was the switch to Cocoa that allowed this to start happening. Or maybe even the switch to Carbon? I know in order to make it happen in 32 bit apps in the very distant past I used the carbon timer API either through declares or in the MBS plugins to make a timer that could fire even while a menu was down. But i cant recall when I stopped having to do that.
It was the switch to Cocoa on the Mac.
The CarbonEventsTimerMBS timer did fire more often than a regular Xojo Carbon Timer.
Also TimerMBS is useful to get a timer firing faster than 1000 times a second.
FWIW, back in prehistoric times (2007) someone named Frank Condello wrote a window class, “Async Drag Window”, that was supposed to not be blocked by mousedown and dragging:
There’s a demo project that puts up two little windows, one standard and one of the “Async Drag” flavor, each with a smoothly updating progress bar. You’re supposed to drag each around to see the effect on progress bar updating. I see no difference between the two under Mac or Windows, and under Mac I see little or no impact from clicking or dragging, but under Windows 10, a 64-bit build has an extremely obvious pause of nearly a second each time either title bar is clicked, and recurring random-length stutters as either window is dragged around.