[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Widget event handlers
- Subject: Re: Widget event handlers
- From: davidf(at)dfanning.com (David Fanning)
- Date: Thu, 1 Mar 2001 22:19:39 -0700
- Newsgroups: comp.lang.idl-pvwave
- Organization: Fanning Software Consulting
- References: <3A9EF042.firstname.lastname@example.org>
- Xref: news.doit.wisc.edu comp.lang.idl-pvwave:23815
Joe Means (email@example.com) 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. :-)
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: firstname.lastname@example.org
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155