Newbie questin regarding Widget timers

I'm working through some of the example code and am trying to
understand the utility of how "animation_doc.pro" uses widget timer
events.

On line 251 of the procedure is the statement:

WIDGET_CONTROL, wBase, TIMER=1

Lines 107-111 in the event procedure capture such events and
generate a new Widget timer event:

IF (TAG_NAMES(sEvent, /STRUC) eq 'WIDGET_TIMER') THEN BEGIN
WIDGET_CONTROL, sEvent.top, GET_UVALUE=pState
; WIDGET_CONTROL, (*pState).wBase, TIMER=1
return
ENDIF

It looks to me that this just continuously fires timer events every
second that do nothing. I commented out the lines mentioned and the
application still runs just fine. So what is the utility of this?

Thanks for you help!

Mike Potter

Mike Potter writes:

> It looks to me that this just continuously fires timer events every
> second that do nothing. I commented out the lines mentioned and the
> application still runs just fine. So what is the utility of this?

Uh, you sure!? TIMERs are one-shot events, so if the
next timer event isn't fired off, things grind to a
halt. Well, they don't exactly grind, they just stop.
It seems unlikely to me that if this line is commented
out, the program just works. Unless you forgot to compile
the program after you made the change, of course. :-)

Cheers,

David

--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")

Hi David:

Yes - I'm sure. I even exited the idlde, restarted IDL, reloaded
the changed version, compiled and ran it, and it ran fine. I even
added a print statement in the middle of the main procedure so that it
would produce something on the console to identify that it was the
altered version that was running. I saved the altered version to my
DEFAULT directory and de-selected all other directories in
Window>Preferences...>IDL>Path to be sure it wasn't picking up a
version from someplace else.

The reason the WIDGET timer stuff seemed superfluous was:

1) the line:

oWindow->SetEventMask, TIMER_EVENTS=1

appears in the branch of the case statement that handles play_button
events in the event procedure


2) the line:
oWindow->AddWindowEventObserver, oObserver

(oObserver is an instance of the custom-defined "timer_observer"
class) appears in the main "animation_doc" procedure,
and

3) there is a timer_observer::OnTimer method defined with oWindow as
it's only argument containing code that sets the ACTIVE_POSITION
within the oImages IDLgrMODEL instance, tnen calls oWindow->Draw.

It's all part of the standard IDL distribution, so if you have
that set up you should be able to try it yourself. I just commented
out the "WIDGET_CONTROL, wBase, TIMER=1" line in the main procedure,
and commented out the lines in the event procedure that checked to see
if the event received was a WIDGET_TIMER event (beginning with "IF
TAG_NAMES(sEvent, /STRUC) eq .......", running from lines 107-111, at
the top of the event procedure).

So, in essence, to these inexperienced eyes, there seems to be two
timer schemes operating simultaneously, one which just fires off a
timer event every one second no matter what, and the other which
drives the animation at a rate that are user-selectable.

Mike



On Aug 28, 3:23*pm, David Fanning <n...@dfanning.com> wrote:
> Mike Potter writes:
> > It looks to me that this just continuously fires timer events every
> > second that do nothing. *I commented out the lines mentioned and the
> > application still runs just fine. *So what is the utility of this?
>
> Uh, you sure!? TIMERs are one-shot events, so if the
> next timer event isn't fired off, things grind to a
> halt. Well, they don't exactly grind, they just stop.
> It seems unlikely to me that if this line is commented
> out, the program just works. Unless you forgot to compile
> the program after you made the change, of course. :-)
>
> Cheers,
>
> David
>
> --
> David Fanning, Ph.D.
> Fanning Software Consulting, Inc.
> Coyote's Guide to IDL Programming:http://www.dfanning.com/
> Sepore ma de ni thui. ("Perhaps thou speakest truth.")

Mike Potter writes:

> The reason the WIDGET timer stuff seemed superfluous was:
>
> 1) the line:
>
> oWindow->SetEventMask, TIMER_EVENTS=3D1
>
> appears in the branch of the case statement that handles play_button
> events in the event procedure
>
>
> 2) the line:
> oWindow->AddWindowEventObserver, oObserver
>
> (oObserver is an instance of the custom-defined "timer_observer"
> class) appears in the main "animation_doc" procedure,
> and
>
> 3) there is a timer_observer::OnTimer method defined with oWindow as
> it's only argument containing code that sets the ACTIVE_POSITION
> within the oImages IDLgrMODEL instance, tnen calls oWindow->Draw.
>
> It's all part of the standard IDL distribution, so if you have
> that set up you should be able to try it yourself. I just commented
> out the "WIDGET_CONTROL, wBase, TIMER=3D1" line in the main procedure,
> and commented out the lines in the event procedure that checked to see
> if the event received was a WIDGET_TIMER event (beginning with "IF
> TAG_NAMES(sEvent, /STRUC) eq .......", running from lines 107-111, at
> the top of the event procedure).
>
> So, in essence, to these inexperienced eyes, there seems to be two
> timer schemes operating simultaneously, one which just fires off a
> timer event every one second no matter what, and the other which
> drives the animation at a rate that are user-selectable.

Well, you are correct that the timer mechanism is not observable
to you. It is buried in the IDLitWindow object and the timer
behavior is controlled by methods to that object. Specifically,
using the SetEventMask method to turn TIMER_EVENTS either on
or off. Once turned on they fire at a user-defined rate until
turned off.

Presumably the IDLitWindow object receives the timer event,
notifies the timer observer or observers of it, then fires
the next timer event. I say "presumably" because this is the
only iTool function on the planet that is hidden from end users.
I have no idea why that is the case. But it is an internal routine,
rather than a routine written in the IDL language and made available
to you.

This is actually quite nice behavior, although it doesn't
particularly help the new user understand how timers work,
because it takes some of the drudgery out of writing the timer
mechanism yourself. This is the only timer program I've ever
seen that is written like this, and of course, it only works
in object graphics. I would bet well over 90% of the programs
written outside the confines of ITTVIS are written in direct
graphics, so that may be why it hasn't come to our attention
yet.

It would be useful to have a direct graphics equivalent of this
behavior and I can see immediately how to add it to my Catalyst
Library of direct graphics widget objects. Then we could all use it.
Well, we could if I ever get around to writing a User Guide for
it. :-)

Cheers,

David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")

David Fanning writes:

> It would be useful to have a direct graphics equivalent of this
> behavior and I can see immediately how to add it to my Catalyst
> Library of direct graphics widget objects. Then we could all use it.
> Well, we could if I ever get around to writing a User Guide for
> it. :-)

If you were interested in how the TIMER mechanism works
outside the confines of IDLitWindow, you can have a look
at XMOVIE, a program meant to expose the workings of timers:

http://www.dfanning.com/programs/xmovie.pro

Cheers,

David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")