| Re: Defining system variables [message #57] |
Fri, 09 August 1991 14:43 |
sterner
Messages: 106
Registered: February 1991
|
Senior Member |
|
|
fireman@stars.gsfc.nasa.gov (Gwyn Fireman) writes:
> I am attempting to create an IDL user environment that uses several
> non-standard system variables. These variables will build upon one another;
> that is, I will define one system variable, then use it to define others.
It sounds like you have a need for global variables. Another
technique that gives something like global variables is to use
a common. If you keep the common in a seperate file, maybe
something like XXX_COM.PRO, it may be included in an IDL routine
by the statement @XXX_COM (starting in column 1). This common is
then included in any routine that needs it, such as an initialization
routine that sets default values in the common. One advantage to
using commons is that you can test if a variable is defined (if
n_elements(x) eq 0 then x is undefined). One disadvantage is that
commons may not be extended while in IDL, so when you add something to
the common you have to exit and re-enter IDL. This is only a problem
during development.
Ray Sterner sterner%str.decnet@warper.jhuapl.edu
Johns Hopkins University North latitude 39.16 degrees.
Applied Physics Laboratory West longitude 76.90 degrees.
Laurel, MD 20723-6099
|
|
|
|
| Re: Defining system variables [message #58 is a reply to message #57] |
Fri, 09 August 1991 13:32  |
fireman
Messages: 49
Registered: August 1991
|
Member |
|
|
FYI, what I found out:
> I am attempting to create an IDL user environment that uses several
> non-standard system variables. These variables will build upon one another;
> that is, I will define one system variable, then use it to define others.
>
I ended up contacting RSI directly. (I was desperate for an answer). As I'm
sure you all know, RSI has a _very_ limited support staff and should be
contacted only when all local resources have been exhausted. Nevertheless, I
have always received prompt, courteous and helpful replies. Thank you, RSI!
RSI answered that there is no need to compile the initialization procedures, as
long as they are in the IDL_PATH. The .run executive command is not valid
syntax unless typed at the command line interactively. Automatic compilation
should take care of my problem of having "undefined" system variables.
> By the way, who is the moderator for this group?
>
rfinch@water.ca.gov (Ralph Finch) and dpf@egretop.gsfc.nasa.gov (David
Friedlander) wrote me to say that there is none. I guess there must be a time
limit for postings to stay available.
Gwyn Fireman phone: (301) 794-1560
Computer Sciences Corporation span: IUEGTC::FIREMAN
IUE Observatory internet: fireman@iue.gsfc.nasa.gov
|
|
|
|
| Re: Defining system variables [message #61 is a reply to message #58] |
Thu, 08 August 1991 13:51 |
thompson
Messages: 584
Registered: August 1991
|
Senior Member |
|
|
In article <6060@dftsrv.gsfc.nasa.gov>, fireman@stars.gsfc.nasa.gov (Gwyn
Fireman) writes...
> I am attempting to create an IDL user environment that uses several
> non-standard system variables. ...
> The problem I have is in compiling the initialization procedures. An
> error occurs when an as-yet undefined system variable is referenced. ...
My suggestion is to use the IDL EXECUTE function for those lines referencing
the as yet undefined system variables. For example,
...
DEFSYSV,'!SYSVAR1','11'
TEST = EXECUTE("DEFSYSV,'!SYSVAR2','2*!SYSVAR1'")
Note the two different kinds of quotes used. This is, admittedly, a little
clumsy.
Bill Thompson
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
