Re: Widget event handlers

[davidf(at)dfanning.com (David Fanning)]

Joe Means (means@fsl.orst.edu) writes:


> In a widget program [TranslateAxies] I am writing I specify an event 
> handler function for each widget that can generate an event.  I specify 
> event handlers for each text and button widget but not for base and 
> label widgets [no bases are resizeable].  No base widgets can be 
> resized.  The GUI includes text boxes for user input.  When I ran the 
> program initially, put text in any box and clicked enter,  I always got 
> the error:
> Attempt to call undefined procedure/function: 'TRANSLATEAXIES_EVENT'.
> 
> So I put a do-nothing procedure with this name in the 
> TranslateAxies_EventCB file.  Now I do not get the error.  Also, all the 
> text widgets and their event functions seem to run fine [when I click 
> return after entering a value in the text field], because their values 
> in the info structure are updated OK. 
> 
> It does not seem like I need this do-nothing proceedure.  Can anyone 
> tell me why it is needed?

No, no one will be able to tell you why it is needed. :-)

It's not needed. Somehow events from this text widget
are not getting sent to the text widget's event handler.
Instead, they are "bubbling up" to the top-level base
event handler, which you have not written, but which would
be named 'TRANSLATEAXIES_EVENT'. In the absence of other
information (e.g., a different name assigned with the
EVENT_HANDLER keyword to XMANAGER) IDL uses the register
name ("translateaxies", in this case) and appends the _EVENT
to it, and assigns this to the top-level base.

I'd guess this was a programming error. (Maybe EVENT_PRO is
mis-spelled, or something like that.) But widgets that have
event handlers assigned to them, *always* send their events
to the proper event handlers. I've never known it to fail. 

And, of course, I'm totally skeptical that the program
is actually "working". :-)

It is often the case in widget programs that we don't want
to deal with text widget events. In other words, most of 
my programs are written in such a way that I totally
ignore text widget events until the user hits the
DOIT button, or whatever. If your program has that
kind of design, I can well believe it appears to
work, even when you are sending text events to a NULL
event handler. That's a design technique I use all the
time. But, in general, it's better to use this design
by choice, rather than by necessity. 

> Also, when I type text in a text widget it will not call the event 
> function to update the value in the info structure if I click tab to 
> move out of the field.  Why is this?

You probably have your text widget set up to only return
Carriage Return events (EDITABLE=1, ALL_EVENTS=0). A 
carriage return is the character String(13B). A tab is
character String(9B). A character return is not a tab.
It's pretty much as simple as that.

Or, another reason this might fail, is that you
are running IDL on a Mac. There, I don't think it
is even possible to trap tabs if you have ALL_EVENTS=1,
since the MacOS has already decided it's going to do
something spiffy with TAB events. (On more mundane
machines, we have to *make* our TAB characters move
to the next input field. What a bother! But one of
the nice features of FSC_FIELD, by the way.)

Sounds like you have almost de-mystified this
widget programming stuff, Joe. :-)

Cheers,

David

-- 
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155