GUI Update Timer Detection

[UrbanCyborg]

Is there some way to tell if there's a GUI update timer in operation already? The debugger is barking at me that I'm trying to start one when there's already one running. I don't think that could be happening unless there were already one running before I started.

[UrbanCyborg]

So, does the lack of response mean no one has any idea? Or that there is no way? Or am I reading too much into silence? Lessee, if a post falls on deaf ears in a forum....

[ColinP]

There's no mechanism to report timers they just produce callbacks in Notify().

But your question doesn't really give enough info to comment on.

What code are you using? What''s the error message? Do you have multiple calls to StartGUIUpdateTimer()?

The only real issue I've had with timers was with multi-threading problems if I started a timer before initialization was fully complete.

Handling thread safety issues properly is something to watch out for in general of course.

[UrbanCyborg]

I call StartGuiUpdateTimer() in the initializer, and have a toggle that runs StopGuiUpdateTimer()/StartGuiUpdateTimer(). The error message occurs during initialization, saying I'm trying to start a Gui Update Timer when one is already running. The code really isn't any trickier than that.

[ColinP]

Does the error message go away if you comment out the StartGUIUpdateTimer() call that's inside Notify()?

If so then take a look at exactly how the toggle button change event is handled during initialization.

[UrbanCyborg]

Oh, good call, Colin! It didn't occur to me that it would treat the toggle's state as changed, requiring notification, on the initial pass through the code, but I guess it does. I was thinking the problem one was the one in the initializer. Commenting that one out still leaves me with the error, and working code, so there must be a Gui Timer active before I manually try to create one. So maybe there's a default 50ms one running before the module's code is even entered.
Danke danke, my friend.

[ColinP]

Just after Initialize() completes you'll get a slew of notifications. One for each knob and toggle. This is how the persistence mechanism works.

The problem sounds like your Notify() code is somehow calling StartGuiUpdateTimer() twice rather than there being some pre-existing timer operating.

Incidentally I don't see why you are starting and stopping the timer in Notify() anyway. The overhead of having the timer going is miniscule so you can just leave it running and do simple tests when you get GUI_Update_Timer events.

I use the timer thread for all kinds of odds and sods so just fire it up in Initialize() and leave it running all the time. Note you should leave calling StartGuiUpdateTime() until the very last statement in Initialize() though as otherwise it's possible to receive a GUI_Update_Timer event BEFORE Initiialize() has finished initializing your objects.

In general be very wary of thread safety issues. Many experienced programmers get tripped up by bugs that only occur in very rare circumstances where code in one thread executes in just the wrong tiny window of time to interfere with code in another thread. Things can look absolutely fine for days, weeks or even months on end and then BANG!

[UrbanCyborg]

The reason I'm toggling it off and on is to implement a "freeze" button. Works fine, and it's a really simple way to do it. I'm not sure why the button would be notified twice during initialization, but I think you're right that that's what's happening. The relevant code is this simple:

Code: Select all

                else if(component == freezeButton) {
                    if(doubleValue == 1.0) 
                        StopGuiUpdateTimer();
                    else
                        StartGuiUpdateTimer();
                }

It's called from the Button_Changed notification.

[ColinP]

Yeah, it does all sound rather odd.

But the way I'd do what I think you're after is to simply start the timer at the end of Initialize(), ignore the button change event and then in the GUI_Update_Timer handler simply use...

Code: Select all

if( freezeButton.GetValue() == ON_VALUE )
	frozenStuff();
else
	unfrozenStuff();

[UrbanCyborg]

Yeah, I thought of doing it that way, but the action needed is simply to stop the module from updating. Stopping the timer does that, because all the action is in the timer notification, rather than in the main process routine. Am I wrong in thinking that the Gui Timer is local to the module? If it's local, then no harm done, because the module doesn't do anything except update the screen; if not, then there could be repercussions. I haven't seen anything to make me think that's the case, though. Admittedly, it does feel a bit kludge-ish. It wouldn't matter if I did it with a named timer, but that wouldn't sync up with the screen refresh, no?