[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Q: debuggging widget applications in IDL 5
- Subject: Re: Q: debuggging widget applications in IDL 5
- From: David Foster <foster(at)bial1.ucsd.edu>
- Date: Fri, 06 Feb 1998 12:21:58 -0800
- Newsgroups: comp.lang.idl-pvwave
- Organization: Univ. of Calif San Diego
- References: <34D1E3C0.76BF@magusxxx.stx.com> <MPG.f3bb014bf2038a1989707@news.frii.com> <EnMByG.DL1@midway.uchicago.edu>
- Xref: news.doit.wisc.edu comp.lang.idl-pvwave:10044
> Mark Rivers wrote:
> >Jack Saba (jackxxx@magusxxx.stx.com) writes:
> >>
> >> Is there any way to get IDL to behave the way it did in IDL 4, or at
> >> least to tell you where the error occurred? I tried using the new
> >> CATCH=0 option on the XMANAGER statement, but either I haven't figured
> >> out how to use it, or this isn't the solution.
> >
>
> In IDL 5 there is a /no_block keyword to XMANAGER. If you set this keyword it
> does 2 things:
> 1) Gives you access to the IDL command prompt even when your widget
> application is running
> 2) Produces the old IDL 4 behaviour when your widget application gets an
> error, i.e. gives you a traceback to where the error occurred
>
> Item 1) above is documented of course, but I don't recall seeing item 2)
> documented. In any event I like both of these behaviours, so I always use
> /no_block.
I wasn't aware that the /no_block keyword caused this behavior (#2).
Perhaps this only works under Solaris 2.X, but I put
XMANAGER, CATCH=0
in our idl_startup file, and we get "IDL 4-like" behavior when errors
occur, whether or not the keyword /NO_BLOCK was used (some of our
applications require its absence).
Dave
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
David S. Foster Univ. of California, San Diego
Programmer/Analyst Brain Image Analysis Laboratory
foster@bial1.ucsd.edu Department of Psychiatry
(619) 622-5892 8950 Via La Jolla Drive, Suite 2240
La Jolla, CA 92037
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~