comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » IDL Runtime
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
Re: IDL Runtime [message #27987 is a reply to message #9138] Wed, 14 November 2001 16:22 Go to previous messageGo to previous message
Andre Kyme is currently offline  Andre Kyme
Messages: 19
Registered: September 2001
Junior Member
Hi David,

Appreciate the reply, but as yet nobody has given me a good explanation of how
XMANAGER works and I don't find the documentation provided by RSI insightful at
all. I'm quite happy to adjust my program design - but I'm not sure exactly how
to do this. People keep replying that "Your program must be so complicated..."
but it is really quite simple! Or at least the IDEA is! I expect the idea would
be a very typical widget programming endeavour!

To briefly describe what my design structure is:

About 5 widget buttons get created and realized to form a menu
Each has an event handler
I call XMANAGER to manage the created widgets
I wait...

Oh, button number 1 was pressed!
Well we better do what event handler number 1 tells us to do.

The event-handler is just a couple of programs that follow one after the other
- is that complicated!! Some of them call other programs - But execution is
just moving sequentially through the event handler routine. Pretty standard I
think.
The actual programs in the event handler involve the user drawing a region of
interest (I don't use draw widgets, just a standard graphics window and a
routine involving the cursor command) and involve moving it around, and also
confirming they are happy with its location.
Now suppose they get fed up with the whole business (like I'm feeling right
now) and want to go and have a coffee - so when they are asked to confirm the
region (I use dialogue_message with the /cancel keyword), they click "CANCEL" -
Why should it be so complicated to just return to your menu options when I
detect the cancellation? This would have to be a pretty standard widget
application surely - menu, option, back to menu, option, back to menu...? What
is the conventional philosophy for doing 'this'?

So again, the design involves having options initially (menu). Some options
aren't relevant initially such as "Save" and "Print", so if the user clicks on
these I issue messages for the user telling them there's no point clicking
these ones yet. The most likely thing they will want to do initially is
"Analysis". "Analysis" is the button with the event handler I described above:
programs that just simply get executed one after the other. During execution of
the event-handler programs, the menu buttons can't be clicked, mainly due to
the fact that the region drawing/moving uses the CURSOR command - so the
computer is waiting for mouse clicks inside the graphics window. (You might
prefer draw widgets w/o CURSOR etc etc, but there's really no problem I can see
with doing it the way I have. It essentially creates MODAL functionality which
ensures the user gets to the end. Anyway I think this is beside the point). But
after this part is done and the results have been displayed, that's the end of
"Analysis". Now they might want to print the results... or do another
analysis...etc.

Also, exactly what DOES happen when instead, the user doesn't get fed up,
finishes the whole event handling routine, and we arrive at the "END" command
at the conclusion of the event-handler? Where is program execution? What is
happening? I'm thinking that we're ready for another menu-button press??

Would appreciate any guidance on a structure,
Thanks,
Andre Kyme
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Chance to Become Famous in IDL Circles!
Next Topic: What's HISTOGRAM doing now?

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Wed Oct 08 19:33:49 PDT 2025

Total time taken to generate the page: 0.00476 seconds