X routines

All GAMAP Routines

List routines by category:
Atmospheric Sciences | Benchmarking | Color | Date/Time | Doc | File & I/O | BPCH Format | Scientific Data Formats | GAMAP Examples | GAMAP Internals | GAMAP Utilities | GAMAP Data Manipulation | GAMAP Models & Grids | GAMAP Plotting | General | Graphics | Math & Units | Plotting | Regridding | Strings | Structures | Time Series

List routines by alphabetical order:
A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z

Last modified: Tue Apr 4 10:50:27 2017.


List of Routines


Routine Descriptions

XCOLORS

[List of Routines]
 NAME:
       XCOLORS

 PURPOSE:
       The purpose of this routine is to interactively change color tables
       in a manner similar to XLOADCT. No common blocks are used so
       multiple copies of XCOLORS can be on the display at the same
       time (if each has a different TITLE). XCOLORS has the ability
       to notify a widget event handler, an object method, or an IDL
       procedure if and when a new color table has been loaded. The
       event handler, object method, or IDL procedure is then responsibe
       for updating the program's display on 16- or 24-bit display systems.

 AUTHOR:
       FANNING SOFTWARE CONSULTING
       David Fanning, Ph.D.
       1645 Sheely Drive
       Fort Collins, CO 80526 USA
       Phone: 970-221-0438
       E-mail: davidf@dfanning.com
       Coyote's Guide to IDL Programming: http://www.dfanning.com

 CATEGORY:
       Color

 CALLING SEQUENCE:
       XCOLORS

 INPUTS:
       None.

 KEYWORD PARAMETERS:
       BLOCK: If this keyword is set, the program will try to block the
          IDL command line. Note that this is only possible if no other
          widget program is currently blocking the IDL command line. It
          is much more reliable to make XCOLORS a modal widget (see the MODAL
          keyword), although this can generally only be done when XCOLORS
          is called from another widget program.

       BOTTOM: The lowest color index of the colors to be changed.

       COLORINFO: This output keyword will return either a pointer to
          a color information structure (if the program is called in
          a non-modal fashion) or a color information structure (if the program
          is called in modal or blocking fashion). The color information
          structure is an anonymous structure defined like this:

             struct = { R: BytArr(!D.Table_Size), $ ; The current R color vector.
                        G: BytArr(!D.Table_Size), $ ; The current G color vector.
                        B: BytArr(!D.Table_Size), $ ; The current B color vector.
                        NAME: "", $                 ; The name of the current color table.
                        INDEX: 0 }                  ; The index number of the current color table.

          If a pointer to the structure is obtained, you will be responsible
          for freeing it to prevent memory leakage:

             XColors, ColorInfo=colorInfoPtr
             Print, "Color Table Name: ", (*colorInfoPtr).Name
             Ptr_Free, colorInfoPtr

          Note that that Name field will be "Unknown" and the Index field will
          be -1 until a color table is actually selected by the user. You are
          responsible for checking this value before you use it.

          When called in modal or blocking fashion, you don't have to worry about freeing
          the pointer, since no pointer is involved:

             XColors, /Block, ColorInfo=colorInfoData
             Help, colorInfoData, /Structure
             Print, "Color Table Name: ", colorInfoData.Name

       DATA: This keyword can be set to any valid IDL variable. If
          the variable is defined, the specified object method or notify
          procedure will be passed this variable via a DATA keyword. This
          keyword is defined primarily so that Notify Procedures are compatible
          with the XLOADCT way of passing data. It is not strictly required,
          since the _EXTRA keyword inheritance mechanism will allow passing
          of *any* keyword parameter defined for the object or procedure that is
          to be notified.

       DRAG: Set this keyword if you want colors loaded as you drag
          the sliders. Default is to update colors only when you release
          the sliders.

       _EXTRA: This keyword inheritance mechanism will pick up and
          pass along to any method or procedure to be notified and keywords
          that are defined for that procedure. Note that you should be sure
          that keywords are spelled correctly. Any mis-spelled keyword will
          be ignored.

       FILE: A string variable pointing to a file that holds the
          color tables to load. The normal colors1.tbl file is used by default.

       GROUP_LEADER: The group leader for this program. When the group
          leader is destroyed, this program will be destroyed.

       INDEX: The index of the color table to start up. If provided, a color
           table of this index number is loaded prior to display. Otherwise,
           the current color table is used. Set this keyword if you wish
           to have the index number of the event structure correct when
           the user CANCELs out of the progam.

       MODAL: Set this keyword (along with the GROUP_LEADER keyword) to
          make the XCOLORS dialog a modal widget dialog. Note that NO
          other events can occur until the XCOLORS program is destroyed
          when in modal mode.

       NCOLORS: This is the number of colors to load when a color table
          is selected.

       NOSLIDERS: If this keyword is set, the color stretch and color gamma
          sliders are not displayed. This would be appropriate, for example,
          for programs that just load pre-defined color tables.

       NOTIFYID: A 2-column by n-row array that contains the IDs of widgets
          that should be notified when XCOLORS loads a color table. The first
          column of the array is the widgets that should be notified. The
          second column contains IDs of widgets that are at the top of the
          hierarchy in which the corresponding widgets in the first column
          are located. (The purpose of the top widget IDs is to make it
          possible for the widget in the first column to get the "info"
          structure of the widget program.) An XCOLORS_LOAD event will be
          sent to the widget identified in the first column. The event
          structure is defined like this:

          event = {XCOLORS_LOAD, ID:0L, TOP:0L, HANDLER:0L, $
             R:BytArr(!D.TABLE_SIZE < 256), G:BytArr(!D.TABLE_SIZE < 256), $
             B:BytArr(!D.TABLE_SIZE < 256), INDEX:0, NAME:""}

          The ID field will be filled out with NOTIFYID[0, n] and the TOP
          field will be filled out with NOTIFYID[1, n]. The R, G, and B
          fields will have the current color table vectors, obtained by
          exectuing the command TVLCT, r, g, b, /Get. The INDEX field will
          have the index number of the just-loaded color table. The name
          field will have the name of the currently loaded color table.

          Note that XCOLORS can't initially tell *which* color table is
          loaded, since it just uses whatever colors are available when it
          is called. Thus, it stores a -1 in the INDEX field to indicate
          this "default" value. Programs that rely on the INDEX field of
          the event structure should normally do nothing if the value is
          set to -1. This value is also set to -1 if the user hits the
          CANCEL button. (Note the NAME field will initially be "Unknown").

          Typically the XCOLORS button will be defined like this:

             xcolorsID = Widget_Button(parentID, Value='Load New Color Table...', $
                Event_Pro='Program_Change_Colors_Event')

          The event handler will be written something like this:

             PRO Program_Change_Colors_Event, event

                ; Handles color table loading events. Allows colors be to changed.

             Widget_Control, event.top, Get_UValue=info, /No_Copy
             thisEvent = Tag_Names(event, /Structure_Name)
             CASE thisEvent OF

                'WIDGET_BUTTON': BEGIN

                     ; Color table tool.

                   XColors, NColors=info.ncolors, Bottom=info.bottom, $
                      Group_Leader=event.top, NotifyID=[event.id, event.top]
                   ENDCASE

                'XCOLORS_LOAD': BEGIN

                     ; Update the display for 24-bit displays.

                   Device, Get_Visual_Depth=thisDepth
                   IF thisDepth GT 8 THEN BEGIN
                   WSet, info.wid

                    ...Whatever display commands are required go here. For example...

                    TV, info.image

                 ENDIF
                 ENDCASE

              ENDCASE

              Widget_Control, event.top, Set_UValue=info, /No_Copy
              END

       NOTIFYOBJ: A vector of structures (or a single structure), with
          each element of the vector defined as follows:

             struct = {XCOLORS_NOTIFYOBJ, object:Obj_New(), method:''}

          where the Object field is an object reference, and the Method field
          is the name of the object method that should be called when XCOLORS
          loads its color tables.

             ainfo = {XCOLORS_NOTIFYOBJ, a, 'Draw'}
             binfo = {XCOLORS_NOTIFYOBJ, b, 'Display'}
             XColors, NotifyObj=[ainfo, binfo]

          Note that the XColors program must be compiled before these structures
          are used. Alternatively, you can put this program, named
          "xcolors_notifyobj__define.pro" (*three* underscore characters in this
          name!) in your PATH:

             PRO XCOLORS_NOTIFYOBJ__DEFINE
              struct = {XCOLORS_NOTIFYOBJ, OBJECT:Obj_New(), METHOD:''}
             END

          Or, you can simply define this structure as it is shown here in your code.

          "Extra" keywords added to the XCOLORS call are passed along to
          the object method, which makes this an alternative way to get information
          to your methods. If you expect such keywords, your methods should be defined
          with an _Extra keyword.

       NOTIFYPRO: The name of a procedure to notify or call when the color
          tables are loaded. If the DATA keyword is also defined, it will
          be passed to this program via an DATA keyword. But note that *any*
          keyword appropriate for the procedure can be used in the call to
          XCOLORS. For example, here is a procedure that re-displays and image
          in the current graphics window:

             PRO REFRESH_IMAGE, Image=image, _Extra=extra, WID=wid
             IF N_Elements(wid) NE 0 THEN WSet, wid
             TVIMAGE, image, _Extra=extra
             END

          This program can be invoked with this series of commands:

             IDL> Window, /Free
             IDL> TVImage, image, Position=[0.2, 0.2, 0.8, 0.8]
             IDL> XColors, NotifyPro='Refresh_Image', Image=image, WID=!D.Window

          Note that "extra" keywords added to the XCOLORS call are passed along to
          your procedure, which makes this an alternative way to get information
          to your procedure. If you expect such keywords, your procedure should
          be defined with an _Extra keyword as illustrated above.

       TITLE: This is the window title. It is "Load Color Tables" by
          default. The program is registered with the name 'XCOLORS:' plus
          the TITLE string. The "register name" is checked before the widgets
          are defined. If a program with that name has already been registered
          you cannot register another with that name. This means that you can
          have several versions of XCOLORS open simultaneously as long as each
          has a unique title or name. For example, like this:

            IDL> XColors, NColors=100, Bottom=0, Title='First 100 Colors'
            IDL> XColors, NColors=100, Bottom=100, Title='Second 100 Colors'

       XOFFSET: This is the X offset of the program on the display. The
          program will be placed approximately in the middle of the display
          by default.

       YOFFSET: This is the Y offset of the program on the display. The
          program will be placed approximately in the middle of the display
          by default.

 COMMON BLOCKS:
       None.

 SIDE EFFECTS:
       Colors are changed. Events are sent to widgets if the NOTIFYID
       keyword is used. Object methods are called if the NOTIFYOBJ keyword
       is used. This program is a non-blocking widget.

 RESTRICTIONS:
       None.

 EXAMPLE:
       To load a color table into 100 colors, starting at color index
       50 and send an event to the widget identified at info.drawID
       in the widget heirarchy of the top-level base event.top, type:

       XCOLORS, NCOLORS=100, BOTTOM=50, NOTIFYID=[info.drawID, event.top]

 MODIFICATION HISTORY:
       Written by:     David W. Fanning, 15 April 97. Extensive modification
         of an older XCOLORS program with excellent suggestions for
         improvement by Liam Gumley. Now works on 8-bit and 24-bit
         systems. Subroutines renamed to avoid ambiguity. Cancel
         button restores original color table.
       23 April 1997, added color protection for the program. DWF
       24 April 1997, fixed a window initialization bug. DWF
       18 June 1997, fixed a bug with the color protection handler. DWF
       18 June 1997, Turned tracking on for draw widget to fix a bug
         in TLB Tracking Events for WindowsNT machines in IDL 5.0. DWF
       20 Oct 1997, Changed GROUP keyword to GROUP_LEADER. DWF
       19 Dec 1997, Fixed bug with TOP/BOTTOM reversals and CANCEL. DWF.
        9 Jun 1998, Fixed bug when using BOTTOM keyword on 24-bit devices. DWF
        9 Jun 1998, Added Device, Decomposed=0 for TrueColor visual classes. DWF
        9 Jun 1998, Removed all IDL 4 compatibility.
       21 Oct 1998, Fixed problem with gamma not being reset on CANCEL. DWF
        5 Nov 1998. Added the NotifyObj keyword, so that XCOLORS would work
         interactively with objects. DWF.
        9 Nov 1998. Made slider reporting only at the end of the drag. If you
         want continuous updating, set the DRAG keyword. DWF.
        9 Nov 1998. Fixed problem with TOP and BOTTOM sliders not being reset
         on CANCEL. DWF.
       10 Nov 1998. Fixed fixes. Sigh... DWF.
        5 Dec 1998. Added INDEX field to the XCOLORS_LOAD event structure. This
         field holds the current color table index number. DWF.
        5 Dec 1998. Modified the way the colorbar image was created. Results in
         greatly improved display for low number of colors. DWF.
        6 Dec 1998. Added the ability to notify an unlimited number of objects. DWF.
       12 Dec 1998. Removed obsolete Just_Reg keyword and improved documetation. DWF.
       30 Dec 1998. Fixed the way the color table index was working. DWF.
        4 Jan 1999. Added slightly modified CONGRID program to fix floating divide
          by zero problem. DWF
        2 May 1999. Added code to work around a Macintosh bug in IDL through version
          5.2 that tries to redraw the graphics window after a TVLCT command. DWF.
        5 May 1999. Restore the current window index number after drawing graphics.
          Not supported on Macs. DWF.
        9 Jul 1999. Fixed a couple of bugs I introduced with the 5 May changes. Sigh... DWF.
       13 Jul 1999. Scheesh! That May 5th change was a BAD idea! Fixed more bugs. DWF.
       31 Jul 1999. Substituted !D.Table_Size for !D.N_Colors. DWF.
        1 Sep 1999. Got rid of the May 5th fixes and replaced with something MUCH simpler. DWF.
       14 Feb 2000. Removed the window index field from the object notify structure. DWF.
       14 Feb 2000. Added NOTIFYPRO, DATA, and _EXTRA keywords. DWF.
       20 Mar 2000. Added MODAL, BLOCK, and COLORINFO keywords. DWF
       20 Mar 2000. Fixed a slight problem with color protection events triggering
          notification events. DWF.
       31 Mar 2000. Fixed a problem with pointer leakage on Cancel events, and improved
          program documentation. DWF.
       17 Aug 2000. Fixed a problem with CANCEL that occurred only if you first
          changed the gamma settings before loading a color table. DWF.
       10 Sep 2000. Removed the requirement that procedures and object methods must
          be written with an _Extra keyword. DWF.
        5 Oct 2000. Added the File keyword to LOADCT command, as I was suppose to. DWF.
        5 Oct 2000. Now properly freeing program pointers upon early exit from program. DWF.
        7 Mar 2001. Fixed a problem with the BLOCK keyword. DWF.
       12 Nov 2001. Renamed Congrid to XColors_Congrid. DWF.
       14 Aug 2002. Moved the calculation of NCOLORS to after the draw widget creation
          to fix a problem with !D.TABLE_SIZE having a correct value when no windows had
          been opened in the current IDL session. DWF.
       14 Aug 2002. Fixed a documentation problem in the NOTIFYID keyword documentation
          that still referred to !D.N_COLORS instead of the current !D.TABLE_SIZE. DWF.
       27 Oct 2003. Added INDEX keyword. DWF.
       29 July 2004. Fixed a problem with freeing colorInfoPtr if it didn't exist. DWF.
        5 December 2005. Added NOSLIDERS keyword and performed some small cosmetic changes. DWF.
       27 Sep 2006. Fixed a problem in which XCOLORS set device to indexed color mode. DWF.
  bmy, 21 Apr 2008: GAMAP VERSION 2.12
                    - Added XCOLORS into GAMAP v2-12 unmodified, 
                      except for minor comment header changes, e.g.:
                      * added ID tag for CVS repository
                      * also changed category to "Color" for
                        compatibility w/ GAMAP documentation

(See /n/home09/ryantosca/IDL/gamap2/color/xcolors.pro)