Re: xloadct: color table from file persists [message #72487 is a reply to message #72360] |
Tue, 07 September 2010 10:12   |
manodeep@gmail.com
Messages: 33 Registered: June 2006
|
Member |
|
|
On Sep 7, 11:25 am, mgalloy <mgal...@gmail.com> wrote:
> On 9/6/10 8:51 PM, Manodeep Sinha wrote:
>
>
>
>> Hi everyone,
>
>> xloadct seems to remember the colors from a non-default color table
>> from an earlier call. I am using IDL 8.0 on Linux (I tested on IDL 7.1
>> and it had the same behavior) and the display is TrueColor.
>
>> Here is the sequence of commands:
>
>> xloadct,file='path/to/brewer.tbl' (and choose some color table)
>> .
>> .
>> xloadct
>
>> The last xloadct command displays the color names from the ITT
>> supplied colors1.tbl but the colors themselves are from brewer.tbl.
>> Regular loadct does not have this behavior (I used David's cindex to
>> verify the loaded colors).
>
>> I did put in a device,decomposed=0 call before the first call to
>> xloadct. xloadct is the correct IDL 8.0 version in the utilities sub-
>> directory.
>
>> Is there any reason that xloadct is designed to behave this way or is
>> something horribly wrong with my IDL setup?
>
> Since LOADCT and XLOADCT get there color tables from the same place
> (unless the FILE keyword is used), I'm not sure what is going on.
>
> Does a restart of IDL get the correct colors? There are some COMMON
> blocks involved, maybe they are getting screwed up in some way?
>
> Mike
> --www.michaelgalloy.com
> Research Mathematician
> Tech-X Corporation
Resetting the IDL session does restore the right colors but that point
is probably moot.
I think I figured the issue out. The problem was the variable
"filename" was not getting
reset when the current file keyword is empty (and filename contains
the file from the
previous call).
xloadct needs to have the following section (the first two lines are
already in xloadct) :
IF N_ELEMENTS(file) GT 0 THEN begin
filename = file
endif else begin
if n_elements(filename) gt 0 then delvarx,filename
endelse
It was a COMMON block issue. Of course.
Cheers,
Manodeep
|
|
|