| Re: Q: debuggging widget applications in IDL 5 [message #10899] |
Fri, 06 February 1998 00:00 |
David Foster
Messages: 341
Registered: January 1996
|
Senior Member |
|
|
> 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~
|
|
|
|
| Re: Q: debuggging widget applications in IDL 5 [message #10947 is a reply to message #10899] |
Fri, 30 January 1998 00:00  |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Liam Gumley (Liam.Gumley@ssec.wisc.edu) writes:
> Just type
>
> XMANAGER,CATCH=0
>
> at the command line *before* you run your widget app, or put it in your
> IDL startup file. It works just fine for me (IDL 5.0.3, SGI Irix 6.2).
This actually DOES work, but apparently for the wrong reasons. :-)
I was just up to RSI today showing them all my weird bugs
and they agreed this was one of them. In the process of showing
it to them I discovered that once I had set Catch=0 and my
program didn't run, that when I removed the Catch=0 my program
actually BEHAVED as if Catch=0 were active! Neat! (This is
how you get rich writing books, by the way, explaining things
like this.)
So, anyway, something weird is going on, but doing as
Liam suggests actually works. To turn the "action" off,
just do this:
XManager, Catch=1
Cheers,
David
-----------------------------------------------------------
David Fanning, Ph.D.
Fanning Software Consulting
E-Mail: davidf@dfanning.com
Phone: 970-221-0438
Coyote's Guide to IDL Programming: http://www.dfanning.com/
|
|
|
|
| Re: Q: debuggging widget applications in IDL 5 [message #10948 is a reply to message #10947] |
Fri, 30 January 1998 00:00 |
rivers
Messages: 228
Registered: March 1991
|
Senior Member |
|
|
In article <MPG.f3bb014bf2038a1989707@news.frii.com>, davidf@dfanning.com (David Fanning) writes:
> Jack Saba (jackxxx@magusxxx.stx.com) writes:
>
>> In IDL 4, when an error occurs in a widget application that uses
>> XMANAGER, the program stops in the module that caused the error.
>> IDL tells you what line the error occurred on and you can look at the
>> variables to get a handle on the problem. With IDL 5, XMANAGER catches
>> the error and returns a message that starts something like
>>
>> XMANAGER: Caught unexpected error from client application.
>>
>> You are not thrown out to the IDL prompt, and you are not told what
>> module the error occurred in.
>>
>> 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.
____________________________________________________________
Mark Rivers (773) 702-2279 (office)
CARS (773) 702-9951 (secretary)
Univ. of Chicago (773) 702-5454 (FAX)
5640 S. Ellis Ave. (708) 922-0499 (home)
Chicago, IL 60637 rivers@cars.uchicago.edu (e-mail)
or:
Argonne National Laboratory (630) 252-0422 (office)
Building 434A (630) 252-0405 (lab)
9700 South Cass Avenue (630) 252-1713 (beamline)
Argonne, IL 60439 (630) 252-0443 (FAX)
|
|
|
|
| Re: Q: debuggging widget applications in IDL 5 [message #10949 is a reply to message #10947] |
Fri, 30 January 1998 00:00 |
Liam Gumley
Messages: 473
Registered: November 1994
|
Senior Member |
|
|
Jack Saba wrote:
>
> In IDL 4, when an error occurs in a widget application that uses
> XMANAGER, the program stops in the module that caused the error.
> IDL tells you what line the error occurred on and you can look at the
> variables to get a handle on the problem. With IDL 5, XMANAGER catches
> the error and returns a message that starts something like
>
> XMANAGER: Caught unexpected error from client application.
>
> You are not thrown out to the IDL prompt, and you are not told what
> module the error occurred in.
>
> 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. Right now it looks like
> we're going to have to keep IDL 4 around just for this.
Just type
XMANAGER,CATCH=0
at the command line *before* you run your widget app, or put it in your
IDL startup file. It works just fine for me (IDL 5.0.3, SGI Irix 6.2).
Cheers,
Liam.
|
|
|
|
| Re: Q: debuggging widget applications in IDL 5 [message #10951 is a reply to message #10947] |
Fri, 30 January 1998 00:00 |
mallors
Messages: 76
Registered: November 1997
|
Member |
|
|
In article <34D1E3C0.76BF@magusxxx.stx.com>,
Jack Saba <jackxxx@magusxxx.stx.com> writes:
> In IDL 4, when an error occurs in a widget application that uses
> XMANAGER, the program stops in the module that caused the error.
> IDL tells you what line the error occurred on and you can look at the
> variables to get a handle on the problem. With IDL 5, XMANAGER catches
> the error and returns a message that starts something like
>
> XMANAGER: Caught unexpected error from client application.
>
> You are not thrown out to the IDL prompt, and you are not told what
> module the error occurred in.
>
> 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. Right now it looks like
> we're going to have to keep IDL 4 around just for this.
>
> If you send email, reply to the address below.
When IDL had their 5.0 seminars a few months back, I mentioned
this problem to RSI, and suggested that XMANAGER print out the
line number of the error statement. We can only hope it's
included in 5.1! I also could not get CATCH = 0 to "do the
right thing", especially when using multiple top level bases.
-bob
--
Dr. Robert S. Mallozzi
University of Alabama in Huntsville
http://cspar.uah.edu/~mallozzir/
|
|
|
|
| Re: Q: debuggging widget applications in IDL 5 [message #10955 is a reply to message #10947] |
Fri, 30 January 1998 00:00 |
Alex Schuster
Messages: 124
Registered: February 1997
|
Senior Member |
|
|
David Fanning wrote:
> Jack Saba (jackxxx@magusxxx.stx.com) writes:
>> XMANAGER: Caught unexpected error from client application.
>>
>> You are not thrown out to the IDL prompt, and you are not told what
>> module the error occurred in.
>>
>> 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.
>
> I can't figure it out, either. When I set Catch=0 on my
> Windows NT machine (IDL 5.0.3) my widgets programs don't
> run at all. Ever. I don't *think* this is how it is suppose
> to work, but nothing I've tried works except just removing
> the CATCH=0 keyword.
Strange. I didn't try NT yet, but on our SUNs it works. I use this line
at the beginning of my programs:
if ( float( !version.release ) ge 5.0 ) then xmanager, catch=0
Alex
--
Alex Schuster Wonko@weird.cologne.de PGP Key available
alex@pet.mpin-koeln.mpg.de
|
|
|
|
| Re: Q: debuggging widget applications in IDL 5 [message #10956 is a reply to message #10947] |
Fri, 30 January 1998 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Jack Saba (jackxxx@magusxxx.stx.com) writes:
> In IDL 4, when an error occurs in a widget application that uses
> XMANAGER, the program stops in the module that caused the error.
> IDL tells you what line the error occurred on and you can look at the
> variables to get a handle on the problem. With IDL 5, XMANAGER catches
> the error and returns a message that starts something like
>
> XMANAGER: Caught unexpected error from client application.
>
> You are not thrown out to the IDL prompt, and you are not told what
> module the error occurred in.
>
> 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.
I can't figure it out, either. When I set Catch=0 on my
Windows NT machine (IDL 5.0.3) my widgets programs don't
run at all. Ever. I don't *think* this is how it is suppose
to work, but nothing I've tried works except just removing
the CATCH=0 keyword.
I deal with the problem of where an error occurs by writing
small, very modular event handlers and by having my own CATCH
error handling in these modules. In this way, I always know
in which module the error occurs. And because the module is
small, a few minutes of detective work can usually isolate
the problem.
But I do wish there was a better solution. What would be
ideal is for there to be a !Line_Number_Error system variable that
gets set whenever an error occurs in a program module.
Cheers,
David
-----------------------------------------------------------
David Fanning, Ph.D.
Fanning Software Consulting
E-Mail: davidf@dfanning.com
Phone: 970-221-0438
Coyote's Guide to IDL Programming: http://www.dfanning.com/
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
