Cocoa, Timer fire like a Thread if MsgBox

Hi,

Did I misunderstood something? A Timer fire while the Application is executing code, in my case the code executed is a HTTPSocket.PageReceived .
I’ve no Thread.

I create a small Desktop Project to do some test. I’ve a button and 2 timers. The Timer1 has a Period = 2. The Timer2 has a period = 1 .
I’ve a button which launch Timer1 , and Timer2 (in this order), so Timer2 fire the first (because shortest period). I do a loop in Timer2 during 3 seconds, so Timer1 shouldn’t launch until Timer2 finish. It’s the case in Carbon, but in Cocoa Timer1 fires while Timer2 is executing its loop.

I found a workarround (relaunch Timer1 latest if Timer2 not ModeOff) but I would like to know if it’s normal or not. I thought the only things which could executing code while MainThread was executing its own code were the Thread, no?

My sample project :
http://throb.pagesperso-orange.fr/Documents/TimerTest.zip
In Timer1 , put FlagWorkArround to True to activate workarround.

You neglected to mention that your Timer2 code calls App.DoEvents. It’s during this time that Timer1 fires.

Using App.DoEvents is not recommended for GUI apps. From the LR:

Ah, too hasty. There is another factor here: Timers in Cocoa run while dialogs are in front. In other words, MsgBox, et al, will stop all other actions with Carbon (and Win/Linux too, I think), but not in Cocoa. Timers will continue to be called, which is really useful. Timers will also run while menus are pulled down and (I think) while windows are being dragged.

Replace your call to MsgBox with System.DebugLog and you’ll see that it works as expected.

No no, I wrote

If FaireEvents Then App.DoEvents

But my flag FaireEvents is False . Note : In French, Faire is Do or Make .

Effectively, I removed the MsgBox and I show a progresswheel1 for Timer1 and a progresswheel2 for Timer2 and it works as expected.
Then calling a MsgBox do the same as write App.DoEvents . I’m not sure it’s normal, and if someone want to do a DoEvent before display a MsgBox, then he write App.DoEvents and then MsgBox “abcd”.
A MsgBox freeze all except Timer ?!!! And it’s then difficult to develop MultiPlateform as a simple MsgBox does not do the same thing on Cocoa than other.

Thank you for your answer.

Can your explain what are you trying to do?

Like: A window with a button and progresswheel, all stopped, but when I click the button… bla,bla,bla,…

Ignore the programming, explain just on the problem.

I run a Timer1. And then I launch another Timer2 while Timer1 is still running. The Timer2 should wait Timer1 finish its code, but if there is a MsgBox in Timer1, then Timer2 fire before the end of Timer1. In Cocoa only, not in Carbon. I didn’t try Windows and Linux.

I didn’t see first it was the MsgBox which cause that, Kem Tekinay wrote it, and effectively it seems to be the MsgBox.

Why not just have Timer1 start Timer 2 at then end of its Action? You can also use a flag to let Timer2 know that Timer1 is still running.

Uhhhh, how did I delete my previos post ? I wanted to edit it and it has been removed without any alert for confirmatio.

Then I wrote that I use a flag (I could also use Timer.mode).

But are you sure it’s normal? I think I will write a bug feedback as nobody from Xojo answered here. If it’s not a bug then they will close my FeedBack.

Not only is it normal, it’s desirable. Having Timers stop because of a dialog or menu pulldown was rather annoying. Think about it: If you have a Timer running that is supposed to do some maintenance every second, do you want it to stop because the user walked away with a dialog up on the screen?

In this case, the Timer fire as soon as the user close the Dialog Box or stop to pull the menu (as soon as the MainThread stop running code).

It could effectively be usefull, but …

I finally wrote a bug Feedback :
<https://xojo.com/issue/29834>
As, as I say in the report each event should happen after the previous event is finish.
You think I’m stubborn?! Sometimes yes, but don’t believe all French are stubborn like me. :smiley:
I’ll call my sister who live in Boston to ask her if New York guys are stubborn too. :smiley: :wink:

I added to your report, so I guess we are. :slight_smile: Sorry, but this behavior is good… no, great, so I wouldn’t want it to change even if they could change it. (I suspect this is a byproduct of the framework so they’d have to put substantial effort into making it work differently.) Since you know the behavior, it is trivial for you to work around it, so I wouldn’t want Xojo to put any time into it even if they were so inclined. If anything, I want Windows and Linux to do it the same way, if they don’t already.