[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: directing control after program interruption
"D. Mattes" <firstname.lastname@example.org> wrote in message
> hello IDL power users: i have a long minimization process running under
> IDL. i would like the user to be able to interrupt the process at any
> time. once the user interrupts by typing ctrl-c, i would like to direct
> program control to a different part of the routine. the only way i know
> to resume the program run is the .continue executive command, but that
> just continues on with the next statement, whereas i would like to branch
> to the end of the routine. is there a system variable that is set when a
> user interrupts program flow? or does this fall into exception handling?
I have a class called MGHwaiter, see
The idea is that, before a long calculation in IDL code, you create an
MGHwaiter object, then in the main loop of the code you add calls to the
object's Yield method. (Each call takes very little time so you can afford
to have a lot of them.) Afterwards you destroy the object. Of course you
can't add calls to Yield inside IDL internal procedures so there are some
time-consuming operations it is not useful for.
Each MGHwaiter object pops up a widget base with 3 buttons: Suspend, Resume
& Abort. Suspend suspends execution (goes into a loop), Resume reverses
Suspend, and Abort calls the MESSAGE procedure to throw an exception. I've
always just cleaned up manually at this point, but you could surround the
Yield calls with a CATCH handler and do whatever you want.
It's all rather clunky, really, but it might be useful for you.
BTW, The MGHwaiter class descends from a procedure that I wrote in 1993. At
that time, IDL on Windows took over the machine completely on long
calculations and the main function of the procedure was to call a Windows
API function called Yield and so allow other applications to get a look-in.
That isn't necessary any more, but the MGHwaiter still has the welcome
side-effect of letting IDL update its display, thus avoiding the
big-blank-window effect on Windows NT.
A detail: MGHwaiter has a rather old-fashioned structure. It calls
WIDGET_EVENT directly & doesn't use XMANAGER. It requires the XMENU routine,
which is obsolete, I think. I think it should be possible to modernise it,
though some calls to WIDGET_EVENT would still be needed.
National Institute for Water and Atmospheric Research
PO Box 14-901, Wellington, New Zealand