| IDL 5.0 observations [message #9092] |
Tue, 27 May 1997 00:00  |
Phil Williams
Messages: 78
Registered: April 1996
|
Member |
|
|
I am initially very impressed with IDL 5.0. I'm still running a preview
release on my Mac (got the UNIX versions last week). Spent the weekend
playing with it and beginning to port my XDISPLAY to objects. What a
speed increase in simple stuff like window and leveling. Here are some
of my complaints/observations (I'm sure some of you have the same ones)
1) Still need better manuals. (There are still places where the ;
comments from code didn't get removed).
2) Better online help (at least on the Mac).
3) There still has to be consistancy in keyword usage. i.e. IDLgrWindow
has keyword COLORMODEL, but WIDGET_DRAW has COLOR_MODEL! Why?
4) I love the fact that I can do a = ( b = intarr(10)) now.
5) help,output=helpSTR is much better than using a seperate function.
6) Pointers are much better than the handles they replace (same
observations made by others here previously).
That's all I can think of for the moment...
Stay tuned for an objectified version of XDISPLAY soon (I hope!)
Phil
|
|
|
|
|
|
|
|
| Re: IDL 5.0 observations [message #9120 is a reply to message #9092] |
Tue, 03 June 1997 00:00  |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
I wrote earlier today in response to a 16-bit color
question:
> For example, to draw a plot in yellow, you might type
> this in 16-bit environment:
>
> PLOT, data, Color=GetColor("yellow", /True)
>
> (I just tried this in IDL 5 running on WindowsNT 4.0
> and it didn't work! I got the plot in white, instead.
> I tried it in IDL 4.0.1 and it worked exactly as I
> expected it to work. I'm finding quite a few bugs in
> IDL 5, so I don't know what to make of this. I'll have
> to do more experimenting.)
This "bug" turns out to be operator error. I forgot
to restart IDL after setting my display to 16-bit
color mode. So, yes, 16-bit color is similar to
24-bit color.
You can also draw a plot in yellow using hexadecimal
notation for the color, like this:
Plot, data, Color='00FFFF'x
Cheers,
David
----------------------------------------------------------
David Fanning, Ph.D.
Fanning Software Consulting
Customizable IDL Programming Courses
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com
|
|
|
|
|
|
| Re: IDL 5.0 observations [message #9123 is a reply to message #9092] |
Tue, 03 June 1997 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
P. Smith writes:
> By the way, I've seen info for getting colours tables set up if running in
> 24 bit mode. I haven't been able to do it for the 16 bit mode (65536
> colours) I run my display in Win95. Everthing plots in red, which is ok
> for line plots but I also need to produce colour contour plots.
Plotting in 16-bit mode is similar to plotting in 24-bit
mode, except that instead of using 8-bits of a 24-bit
value for each color, in 16-bit mode fewer bits are
used. (I think it is 6 bits of red and 5 of blue and
green, but I can't remember exactly. 64x32x32 = 65536.)
I have a couple of articles on my web page that talk
about 24-bit color, but the same principles apply to
16-bit color. There are also a number of programs to
help you work in this color environment. For example,
to draw a plot in yellow, you might type this in a
16-bit environment:
PLOT, data, Color=GetColor("yellow", /True)
(I just tried this in IDL 5 running on WindowsNT 4.0
and it didn't work! I got the plot in white, instead.
I tried it in IDL 4.0.1 and it worked exactly as I
expected it to work. I'm finding quite a few bugs in
IDL 5, so I don't know what to make of this. I'll have
to do more experimenting.)
Cheers,
David
----------------------------------------------------------
David Fanning, Ph.D.
Fanning Software Consulting
Customizable IDL Programming Courses
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com
|
|
|
|
|
|
| Re: IDL 5.0 observations [message #9146 is a reply to message #9092] |
Fri, 30 May 1997 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
David Foster writes:
> Yet more IDL 5.0 observations:
> 2. What leads to even more editing is the fact that you should not
> use EVENT_PRO or EVENT_FUNC keywords in the WIDGET_BASE() call,
> use EVENT_HANDLER in XMANAGER instead. This means that for all
> popup utility windows that generate events for their applications,
> and for each application in turn, you have to modify the widget
> creation code. Again, a pain if you have many applications.
Actually, I don't think this has changed. The event handler for
the top-level base should *always* be assigned with the XMANAGER
call and *never* with EVENT_PRO. This was true in IDL 4.0, as I
learned only too well after a couple of *very* long evenings
debugging code. I think it is just better documented in IDL 5.0. :-)
> Now that all the crud is taken care of I'm hoping to play around
> with the new features like pointers and OOP stuff. I have a feeling
> I'll be impressed.
I have to say, pointers are blowing me away. They are SOoooo
nice! The only thing I miss about handles (it is a small thing)
is that I could free up the whole lot of them by freeing
the parent. And I am also greatly impressed with how little
effort is required to switch between handles and pointers,
at least in my code. This is a nice job, RSI!
I'm having a few problems with resizeable graphics windows
getting "stuck" at a particular size in certain circumstances,
but so far it's not too bad and I've managed to find work-
arounds.
Cheers,
David
David
----------------------------------------------------------
David Fanning, Ph.D.
Fanning Software Consulting
Customizable IDL Programming Courses
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com
|
|
|
|
| RE: IDL 5.0 Observations [message #9181 is a reply to message #9092] |
Mon, 09 June 1997 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Folks,
I just got this report from Lena Marshak via e-mail
and confirmed that the behavior is as she describes it
on my WindowsNT machine, too.
David
------------------------------------------------------------ -----------
Name: Jelena Marshak
E-mail Address: lena@fram.gsfc.nasa.gov
IDL version: IDL Version 5.0 (sunos sparc)
Platform and OS: Ultra1 Creator w/ Solaris 2.5 (CDE 1.0)
Description of Problem: -----------------------------------------------
I am trying to polyfill a rectangle on a cylindrical map projection.
The rectangle runs along a line of latitude, and so should be a straight
line. (Which it is in IDL 4.0.) Instead, this line looks like a inverted
"V".
Example Code: ---------------------------------------------------------
Map_Set, /Grid, /Continent
TVLCT, 255, 255, 0, 35
lon=[-81.2500,83.7500,83.7500,-81.2500]
lat=[28.7500,28.7500,31.2500,31.2500]
Polyfill, lon, lat, Color=35, /Data
Known Workarounds or Fixes: -------------------------------------------
None known.
RSI Technical Support Response: ---------------------------------------
Pending.
|
|
|
|
| Re: IDL 5.0 Observations [message #9183 is a reply to message #9092] |
Mon, 09 June 1997 00:00 |
Andy Loughe
Messages: 174
Registered: November 1995
|
Senior Member |
|
|
> Example Code: ---------------------------------------------------------
>
> Map_Set, /Grid, /Continent
> TVLCT, 255, 255, 0, 35
> lon=[-81.2500,83.7500, 83.7500,-81.2500]
> lat=[ 28.7500,28.7500, 31.2500,31.2500]
> Polyfill, lon, lat, Color=35, /Data
>
> Known Workarounds or Fixes: -------------------------------------------
>
> None known.
>
> RSI Technical Support Response: ---------------------------------------
>
> Pending.
Hi Lena, this is your old officemate, Andy!
A known workaround would be to include the Greenwich Meridian when
specifying the coordinates of a polygon which crosses longitude=0.
Your example becomes...
Map_Set, /Grid, /Continent
lon=[-81.25, 0.00, 83.75, 83.75, 0.00, -81.25]
lat=[ 28.75, 28.75, 28.75, 31.25, 31.25, 31.25]
Polyfill, lon, lat, Color=35, /Data
This should work for IDL 4 and 5. A similar workaround is needed
when crossing the dateline and using polyfill in version 5.
Thanks for pointing this out! Let's hope it gets fixed.
--
Andrew F. Loughe |
afl@cdc.noaa.gov
University of Colorado, CIRES Box 449 |
http://cdc.noaa.gov/~afl
Boulder, CO 80309-0449 | phn:(303)492-0707
fax:(303)497-7013
------------------------------------------------------------ ---------------
"I do not feel obliged to believe that the same God who has endowed us
with
sense, reason, and intellect has intended us to forego their use."
-Galileo
|
|
|
|
| Re: IDL 5.0 observations [message #9193 is a reply to message #9092] |
Sun, 08 June 1997 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Folks,
I notice that when I put axes on a surface plot that the
X axis title appears to almost touch the numbers that
label the axis. The Y and Z axis titles are much
further away from their respective numbers. You
can see this if you look at the surface plot
in the XSURFACE program at:
http://www.dfanning.com/documents/programs.html
Does anyone else notice this, or is this a windows
problem. I'm running WindowsNT 4.0.
BTW, this appears to not be an optical illusion
or an accident of perspective, because it holds
true under any rotation.
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Customizable IDL Programming Courses
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com
IDL 5 Reports: http://www.dfanning.com/documents/anomaly5.html
|
|
|
|
| Re: IDL 5.0 observations [message #9214 is a reply to message #9092] |
Fri, 06 June 1997 00:00 |
thompson
Messages: 584
Registered: August 1991
|
Senior Member |
|
|
davidf@dfanning.com (David Fanning) writes:
> Folks,
> Just a note about IDL 5.0. It has been brought to my attention
> that the actions of GET_KBRD() has been changed in IDL 5.0.
> In IDL 4.0.1 you could type this code:
> ok = Get_KBRD(1)
> And a Carriage Return character was a valid character to be
> read from the keyboard. People have used this code in programs,
> for example, to implement a "Hit any key to continue" type of
> action.
> In IDL 5.0 a Carriage Return is no longer a valid character
> for this command, along with other editing keys such as
> backspace and delete. Users will now have to hit a valid
> alphanumeric key to continue.
Isn't backwards compatibility wonderful?
Bill Thompson
|
|
|
|
| Re: IDL 5.0 observations [message #9219 is a reply to message #9092] |
Thu, 05 June 1997 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Folks,
Just a note about IDL 5.0. It has been brought to my attention
that the actions of GET_KBRD() has been changed in IDL 5.0.
In IDL 4.0.1 you could type this code:
ok = Get_KBRD(1)
And a Carriage Return character was a valid character to be
read from the keyboard. People have used this code in programs,
for example, to implement a "Hit any key to continue" type of
action.
In IDL 5.0 a Carriage Return is no longer a valid character
for this command, along with other editing keys such as
backspace and delete. Users will now have to hit a valid
alphanumeric key to continue.
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Customizable IDL Programming Courses
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com
IDL 5 Reports: http://www.dfanning.com/documents/anomaly5.html
|
|
|
|
| Re: IDL 5.0 observations [message #9232 is a reply to message #9092] |
Thu, 05 June 1997 00:00 |
Stein Vidar Hagfors H
Messages: 32
Registered: May 1997
|
Member |
|
|
Another change to the widget handling that I've found
is that calling XMANAGER without any arguments will no
longer resume event processing when called from "within"
another XMANAGER call.
Some times, I like to be able to have widget "A"'s event
procedure "A_EVENT" read in data, start off widget B
from within A_EVENT to display the data, *without* making
A modal (so you can read and display other data sets from A),
but still let the call to B *not* "fall through" - i.e., to
delay the return from B until B actually dies and no longer
needs the data passed to it.
This is handy for those situations where B uses a NO_COPY
operation that would make it's arguments undefined upon
an immediate return.
I'm aware that making B "hang" without modalizing A will
allow A to be killed before killing B (when the return from
B to A_EVENT comes, A may not be valid), but that's quite
OK: The point is that the arguments passed to B may have to
be returned to the user who started A from the prompt, so
A_EVENT needs to get it's hands on the arguments to B *after*
B dies.
In v 4.0.1 one could do this by using something like
XMANAGER,"B",BASE
WHILE WIDGET_INFO(BASE,/VALID_ID) DO XMANAGER
in program B, but this now causes an infinite loop calling
XMANAGER without causing events to be processed (but taking
100% cpu power).
This may not be a big problem, but it's at least a significant
change in the way XMANAGER behaves.
Stein Vidar
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
