POW works in terms of objects (although at the moment, it's not written 
using object-oriented TCL).  Each of these objects has a name (just an 
ASCII string).  Once an object is "constructed", you use the name
to refer to it in the various things you want to do to it ("methods").
The main objects are:

PowData - this object is an array (in the C sense) in memory somewhere
          along with info on data type and the length of the array.
          At creation, you can specify that POW should make it's own copy
          of the data, allowing you to "free" your copy, or you can save
          space by allowing POW to use your copy of the data, just don't
          free or change it unless you destroy the PowData object first.

PowVector, PowImage - these are your choices for what you can create using
          your PowData, they give "physical" meaning to the data by specifying
          units and, for images, dimensions.  You can make any number of 
          Images and Vectors from one chunk of Data, and you can specify 
          offsets so as to use only part of the Data.

PowCurve - This is a collection of 1 to 6 vectors which represent a curve in
           space and its associated errors. Currently, nothing is done
           with the z and z-error vectors, but suggestions are welcome.

PowGraph - This is the only *displayed* object in POW.  I.e. you can display
           your Images and Curves only by creating a Graph with them as 
           members, or by plotting them on an existing Graph (at which
           point they become part of that Graph).  One Image or vector
           can, of course, appear in any number of Graphs.  


The TCL interface:

*arguments in angle brackets are optional


"Constructors"
powSetupColormap  toplevel free_cells ?force_cmap? ?options? -
	You should call this to create the first toplevel window for your
	application unless you really want to do your own colormap 
	management.  This proc will use the default colormap if it can
        allocate enough colors or will allocate a Private pseudocolor colormap
        with an	attempt to minimize flashing.  If this fails to find any
	pseudocolor visuals, it will use the default colormap and disable
        pseudocolor images in POW.

	toplevel - this is the name of the toplevel you want to create.
	           it should probably be the first toplevel your application
                   creates (e.g. .mytop)  and all subsequent toplevel creation
                   statements should include a "-colormap .mytop" option.

	free_cells - the number of colors your application will need in 
	             addition to what POW allocates for itself.  If you get
	             BadColor errors (or the like) in your application, try 
	             making this number bigger.  If you keep getting a Private
                     colormap when your Default colormap is full, try making 
	             this number smaller.
	
	force_cmap - Forces different colormap behaviors.  You might want 
                     to give your users a way to set this themselves.: 
	           0 - Default behavior.  I.e. choose the "best" colormap.
	           1 - Force POW to setup a new private pseudocolor colormap 
                       (very safe)
                   2 - Force POW to use truecolor mode (very safe, but 
                       looks bad on low color displays and runs slower than
                       pseudocolor).  Note: this will cause powSetupColormap
                       to look for a truecolor visual; if it can't find one,
                       it will allow the main Tk code to pick a visual,
                       but POW will still use "truecolor mode" (i.e. the
                       Tk photo widget) to display images.
                   3 - Force use of the screen default colormap. This should
                       be reasonably safe now, but often won't be what you
                       want.
                       
 
	options - a string of extra options to hand to the toplevel creation
                  command, if you need them.
	
	See comments under powInit for more details.


powInit ?XColormapWindow? ?container? ?powGUI? - creates the .pow toplevel 
	window, all the user interface buttons and the .pow.pow
        canvas.  The second optional argument is the pathname of a 
	container window for POW if you want to embed POW in your own
        toplevel (only works for Tcl/Tk8.0 and later versions). 
	The first optional argument is the name of a window in your
	application and tells POW to use the same X colormap as that
        window;  this will allow your user to reliably see both POW
        and your application in the proper colors at the same time.
        Note, if you give an argument to powInit, that window should 
	have a pseudocolor visual with at least 60 free read-write 
	colorcells (call powSetupColormap first) or POW will disable 
        pseudocolor images.  The third argument indicates wether you 
        want POW to wrap its main canvas in an enduser GUI. Unless
        you're embedding POW in a specialized application, you'll
        want to leave this at the default of 1; a value of 0 removes
        the GUI.

	If you call 'powInit none' (or with no argument) pow will handle 
	its own colormap needs, but if it creates a private colormap, you 
	will see serious flashing between your application's windows and 
	the POW window.

	Usually, the window you specify for powInit would be the toplevel
        window for your application and you should use powSetupColormap
        to avoid excessive flashing and Xlib induced crashes.  Make sure 
	you create any other toplevels with the same colormap. Unfortunately,
        Tk has a stupid default behavior for picking the visual of a 
        new toplevel when it's colormap is specified, so it's recommended
        that you use powToplevel to create all your toplevels (sorry folks,
        this one's not my fault). Ok, since this is probably confusing, 
  	here's an example.

	Suppose (for argument) your application uses 10 colors (for 
	backgrounds highlights, etc) and your application's main window
	is '.mytop'.  And you want the background of your application to
        be pink and you want it to be 100 pixels wide.  
	When you create .mytop instead of calling 'toplevel', instead do:

	powSetupColormap .mytop 10 0 "-background pink -width 100"
         
        Invoke POW with:

	powInit .mytop

        If you create any other toplevel windows, be sure to create
	them with:

        powToplevel .mydialogbox .mytop

	If you need to pass other options to "toplevel", put them 
        all in one string like:

        powToplevel .mydialogbox .mytop "-class \"My Extra Window\" -bg blue"

powToplevel topwin refwin ?option_string? -
	This is a replacement for the Tk toplevel command.  The Tk toplevel
        command with a "-colormap" argument but no "-visual" argument 
        *doesn't* use the visual of the given colormap to create the new 
        window; instead it uses the screen default visual and then dies
        if they're not compatible.  Why? Who knows? 

  topwin  The name of the toplevel you want to create.

  refwin  The window whose colormap you want to use.

  option_string  Any other options you want to pass to the "toplevel" command.
          This needs to be a single string.

        If you don't want to call powToplevel, doing this yourself is simple.
        Here's the code for the powToplevel proc:

proc powToplevel {topwin refwin {options ""}} {
#this implements what *should* be default behavior.  Apparently the evil
#of Xlib colormap handling is contagious.

    eval "toplevel $topwin -colormap $refwin -visual \"[winfo visual $refwin] [winfo depth $refwin]\" $options"

}
       


powCreateData data_name data_pointer data_type length ?copy? -
           This "constructs" a PowData object.  The other ways
           to create PowData at present are with the powCreateVectorEN
           or the powCreateDataFromList commands, see below.

  data_pointer  This argument will probably be the return value from either:
                $fitsfile load image
                   or
                $fitsfile load column
                See fitsTcl documentation for details.  Or you can write your
                own TCL command to make data.  Just have it return a void
                pointer formatted with:
                sprintf(interp->result,rstring,"%p",(void *)dataptr);

  data_type     This is one of the strings (or an integer):
                  "BYTE"     or  0  or   8                   1 byte
                  "SHORTINT" or  1  or  16                   2 bytes
                  "INT"      or  2  or  32                   4 bytes
                  "REAL" or "FLOAT" or 3 or -32              4 bytes
                  "DOUBLE"   or  4  or -64                   8 bytes

                Note: 8 byte integers are not supported at this time

     
  copy          If copy is a positive integer, POW makes its own copy of the 
                data array and uses that, freeing it when the object gets
                destroyed.  If copy is zero, POW uses the supplied
                data_pointer directly (no copy), but does not try to free
                it when destroyed.  If copy is negative, POW takes ownership
                of the data_pointer, using it directly and freeing it when
                the object gets destroyed.  In this last case, the
                data_pointer *must* have been allocated using TCL's
                ckalloc() function (always true for data from fitsTcl). 
                The default value is 0.


powCloneData new_data_name old_data_name ?offset? ?length? ?copy?
        This creates a new PowData object from an existing PowData object.
        !!Use this function with caution unless you are specifying 
        a copy flag > 0 or you could wind up with POW Data objects that
        point to invalid areas of memory if you destroy one of the 
        partners of the clone but not the other!! 
       
        Returns the length of the new POW Data object.

  offset    Specifies an offset to the starting point of the data
            in memory. Default is 0.

  length    How much of the old data do you want to use?  If you specify
            "NULL" the new data will have the same endpoint as the
            old data.  If you specify a length that ends beyond the end 
            of the previous data, the length will be adjusted to match
            the endpoint of the old data. Default is "NULL".

  copy      If copy is a positive integer, POW makes a new copy of the 
            old data array and uses that, freeing it when the object gets
            destroyed.  If copy is zero, POW uses the old data pointer
            (plus offset) directly (no copy), and does not try to free
            the memory when the new data object is destroyed.  If copy is 
            negative, POW will flag the new_data_name as the "owner" of
            the data array so destroying the old_data_name will not
            free the associated memory, but destroying the new_data_name
            will.  If you specify copy < 0 and offset != 0, powCloneData
            will return an error.  The default value of copy is 0.

powCreateDataFromList data_name list_o_data ?stringflag? -
	This creates a PowData object using the contents of a TCL list.
        The data object will be of type DOUBLE unless stringflag is
        is Yes.  String data should only be used as the "z" vector
        of a PowCurve object, in which case, the specified string will
        be plotted at the position given by the corresponding x and y
        values.

powRegisterData powdata_pointer
        If you have an application that creates it's own PowData objects (like
        the LHEA orbit library or the internal routines in TAKO), you must
        "register" them in the main PowData hash table in order to use
        them in plotting functions.  Naturally, if the PowData objects
        aren't properly or fully created, you could run into trouble.
        The pointer is a string created the same way as described above for 
        the data_pointer argument to powCreateData, except that it should
        be a pointer to a PowData structure rather than to a simple array.

powCreateVector vector_name data_name offset length units - 
           Creates a PowVector. If length is "NULL" uses the length
           of the Data.

powCreateVectorEN vector_name data_name length start increment units -
           Creates a vector and the data to go with it.  This is nice
           for generating test data among other things.  You *can*
           make a PowImage using the data this generates, by the way.
           (EN stands for Ex Nihilo)

powCreateImage image_name data_name xoffset yoffset width height xorigin \
xinc yorigin yinc xunits yunits zunits - 
           Creates a PowImage.  The xorigin and xinc arguments are the origin
           and pixel size in the units specified in the xunits and yunits 
           arguments.

powCreateCurve curve_name x_vector x_error y_vector y_error ?z_vector z_error?
         - Creates a PowCurve (displayable).  All but one of the component
           vector arguments can be the string "NULL" and POW will deal with 
           it in a hopefully sensible default manner. The length of the 
           curve will be the length of the first non-null vector (I might
           change this to be length of the shortest vector present).
           I'm also thinking of allowing scalar errors indicated by an 
           "=" sign in the argument (but this isn't done yet).

	   POW curves are now implemented with a new canvas item type.
	   For a curve named ACURVE displayed on a graph named BGRAPH,
           the powCurve item has a tag "ACURVEBGRAPH".  powCurve supports
           most of the options available for the Tk native "line" type.
           So to change the fill color of ACURVE to blue and make it a dashed
           line (5 pixel dashes) do:

           .pow.pow itemconfigure ACURVEBGRAPH -fill blue -dash 5

           The only use of z_vector so far is if the z_vector is
           created from STRING type data (e.g. using powCreateDataFromList),
           then the strings will be printed at the positions given by the
           corresponding x and y elements.


powCreateGraph graph_name curves images xunits yunits xlabel\
         ylabel ?xdimdisp ydimdisp xmin ymin xmax ymax?	 -
	 This is the main one that actually draws on the .pow.pow canvas. 
	 See discussion of powStartNewRow below to see how POW decides 
	 where to place incoming graphs.  Some details (hopefully the
	 rest is self-explanatory):

  curves, images - these are Tcl "lists" of PowImages and PowCurves to plot
  
  xunits, yunits - These are the physical units associated with an axis
         and will be printed next to the label.

  xlabel, ylabel - An optional label for each axis.  The y-axis label will
         be printed horizontally at the top of the y-axis since the Tk 
         canvas does not allow rotated text at this time.
  
  xdimdisp, ydimdisp - the "maximum size" for the display of the graph in
          screen pixels. The graph will be shrunk or expanded from its
          "natural" size to fit into an area of the canvas of this requested
          size.  If "NULL" is passed, a default value will be used.

  xmin ymin xmax ymax - the bounding region for the displayed area of a 
          graph.  These are in the units of each respective axis.  Parts
          of images or curves falling outside this box will not be plotted.
          Each of these arguments can be a list if more than one y or x axis is
          present.

powGraphOptions graph_name option value ?option value option value ...? -
	This function was added to allow easy customization of several
        (more every day :) additional options that would have been too 
        unweildy to add to the already too long powCreateGraph call.
        Specify as many option value pairs as you like.  Boolean values
        should have values of Yes/No if one wants POW's menus to properly
        reflect the new values.  In addition to all of the arguments to
        PowCreateGraph, current options are:
	
	bgcolor - A background color for the whole graph
	
	xmargin - The amount of space around a graph (in pixels by default)
	ymargin - This will only affect subsequent operations on the graph
                  (chain alignments, replottings, etc.), it doesn't move
                  the graph immediately.

        handletext - Change the text that normally says:
	           "Select/Move: graphname"
        handleanchor - Change the anchor point of the handletext. Default
                   is "sw".
        handleposition - Change where on the graph's bounding box the 
                   handle is anchored to.  Choices are:
	           t - midpoint of top
                   l - midpoint of left side
                   b - midpoint of bottom
                   r - midpoint of right side
                   Combine to get corners.  Default is "tl".

        xNumTicks   - An integer number used to indicate how many ticks to
                      place on the X axis.  3-6 are reasonable values.
        yNumTicks   - An integer number used to indicate how many ticks to
                      place on the Y axis.  3-6 are reasonable values.
	xTickLength - 4 element list indicating how long to draw the x
                      tick marks on each of the 4 sides of the graph.  Order
                      is {left right top bottom}.  Negative values cause
                      tickmarks to be drawn inside the graph box.
	yTickLength - Same for y tick marks.
	xLabelTicks - 4 element boolean list indicating whether the x tick
                      marks should be labeled along each side of the graph.
                      Order is {left right top bottom}.
	yLabelTicks - Same for y tick labels.
        xTickScal   - Scaling method for the X tick marks.  Valid values
                      are "linear", "wcs" (for celestial coordinates/right
                      ascension), or "log" (for logarithmic scaling).  Tick
                      marks and labels will be drawn accordingly.  WCS scaling
                      occurs only if WCS information exists for the graph.
                      Logarithmic scaling *does not* affect the drawing of
                      curves (ie, curve data are assumed to be in logarithmic
                      format).
        yTickScal   - Same for y ticks.  WCS scaling assumes declination
                      values for the y axis, though.
        GridLines   - A boolean value indicating whether to draw grid lines
                      connecting the graph's tick marks
        GridColor   - The color of the grid lines
        GridDash    - Dash value of the grid lines.  Formats are:
                        " "    - Solid line
                        "10"   - 10 pixel dashes and spaces
                        "15 5" - 15 pixel dashes, 5 pixel spaces
                        "15 10 5 10" - Dash-dot
                        etc.
        useSixties  - A boolean value indicating whether to attempt to use
                      base 60 tick marks (works only with WCS data).

powSetCurveOptions graph curve ?option value option value ...? -
        This function allows one to set the display parameters for a curve
        in the indicated graph.  If this function is not called *prior* to
        creating the graph, a curve will be assigned default values.  When
        called after the graph is created (and curve plotted), this function
        will update the appearance of the curve in both the main graph and,
        if it is the current graph, the scopebox.  The allowed options and
        values (boolean values should be Yes/No) are:

           Option Name    Value Type    Option Meaning
             pDisp     -->  boolean  -->  Display Points?
             pShape    -->  string   -->  Point shape (Cross, Diamond, Box,
                                             Octagon, Triangle, "Inv. Triangle")
             pSizeErr  -->  boolean  -->  Draw point the size of errorbars?
             pSize     -->  integer  -->  Size of point
             pFill     -->  boolean  -->  Fill in point, if an outline
             pColor    -->  color    -->  Color of points (any color name
                                             or #RRGGBB value)
         	       	    	     	  
             lDisp     -->  boolean  -->  Display line?
             lStyle    -->  dash     -->  Dash style of line (" " is solid, 
                                             "20" is 20-pixel dashes,
                                             "15 10 4 10" is Dash-dot, etc)
             lWidth    -->  integer  -->  Width of line
             lStep     -->  boolean  -->  Draw line as histogram?
             lBoxFill  -->  boolean  -->  Fill histogram boxes?
             lColor    -->  color    -->  Color of line (any color name
                                             or #RRGGBB value)

        If no option/value pairs are given, this function will return all the
        defined options.  If the curve has been drawn already, all the options
        will be defined.

powSetImageOptions graph image ?option value option value ...? -
        This function allows one to set the display parameters for an image
        in the indicated graph.  If this function is not called *prior* to
        creating the graph, an image will be assigned default values.  When
        called after the graph is created (and image plotted), this function
        will update the appearance of the image in both the main graph and,
        if it is the current graph, the scopebox.  It will also update a
        colorbar (or if changing a colorbar option, the original image).
        The allowed options and values (boolean values should be Yes/No) are:

           Option Name    Value Type    Option Meaning
             colormap  -->  string   -->  Which colormap to use
             invert    -->  boolean  -->  Invert colormap?
             scale     -->  string   -->  Scaling law to use to create the
                                             colormap (linear, sqrt, log)

        If no option/value pairs are given, this function will return all the
        defined options.  If the image has been drawn already, all the options
        will be defined.


"Destructors"

powDestroyX  Xname  - Destroys the named POW Object.  "X" can be:
                      Graph, Curve, Image, Vector, or Data.  Be careful,
                      don't destroy a low-level object (e.g. data) before
                      destroying a high-level one that depends on it (e.g.
                      Graph or Curve); the destructors don't (yet anyway)
                      search through all objects to handle these dependencies,
                      it's up to you to keep track of them if you need to.
                      The POWData destructor *will* free the associated 
                      memory if the Data object was created with the 
                      copy flag set.


"Methods" 

powPlotCurves graph curves ?canvas?- adds the list of Curves to an existing
                                     Graph on the Canvas (default .pow.pow)

powAddCurves graph curves - adds the list of Curves to an existing Graph,
                            updating the scope box as necessary

powPlotImages graph images - adds the list of Images to an existing Graph

powMagGraph graph xMagstep yMagstep - resize a Graph to the given X and Y
              magsteps (magstep = 1 is the "natural" size of the graph).
              Magsteps can be any real value and X and Y may be different.

powStretchGraph graph xFactor yFactor - shrink or grow a Graph by the given
                 X and Y factors.

powStretchGraphToSize graph xDim yDim - Set the size of the Graph to the
                 given X and Y dimensions (in pixels).

powStartNewRow - POW displays incoming graphs are placed to the right
                 of all existing  material in the current "row".
	         A "row" is defined by an (invisible) line on the graph.
                 Initially this boundary line is 10 pixels from the
                 top of the canvas.  powStartNewRow moves this line to
                 just below all material currently displayed on the
                 canvas.  To make a 3x2  "grid" of graphs do:

	         %powCreateGraph graph1 ...
	         %powCreateGraph graph2 ...
	         %powCreateGraph graph3 ...
                 %powStartNewRow	
	         %powCreateGraph graph4 ...
	         %powCreateGraph graph5	 ...
	         %powCreateGraph graph6	 ...
                  
                 If the end-user moves or resizes something during
                 this process, you won't get a strict rectangular
                 grid, but new graphs will not land on top of existing
                 ones.


Note:  %x and %y return cursor positions in X coordinates, to turn
       these into canvas coordinates, use '.pow.pow canvasx %x' etc.


General Interface Concepts

The general way for a developer to get back info from
his users would be to bind the left mouse button on the .pow.pow
canvas to whatever you want it to do (the only things on the canvas
that are currently bound to the left mouse button are the "purple"
handles, so this should be safe).  Once you've got a coordinate (or
set of coordinates) use '.pow.pow canvasx' and 'powCanvasToGraph graph
X' to find out what physical coordinates your user is interested in.
powWhereAmI can tell you which graph they appear to be inside of if
you need to know that easily.

If you set the global variable powClickCallback, <ButtonPress-1>, 
<Double-Button-1>, <ButtonPress-2>, or <ButtonPress-3> events on the
main POW canvas will fire your callback with the arguments "graphname
x y binding" where: 

graphname - is the graph the user clicked inside of, if they click outside of
            all graphs, nothing happens
x and y - are the graph (i.e. "physical") coordinates of the point they 
          clicked.
binding - is the X event which fired the callback currently the only strings
          returned are "B1", "B2", and "B1D" (for double clicking button 1)
          but if you'd like to see more bindings,  let me know ("B3" is 
	  currently in use for Region of Interest zooming).

If you set the global variable powPreScrollCallback or powPostScrollCallback,
when the user manipulates a scrollbar on the main .pow.pow canvas,
your callback will be fired with the same arguments as would be
recieved by the function specified in a '-command' argument to the
scrollbar creation command.  See the Tk scrollbar documentation 
for details.  The "Pre" form will fire your callback *before* the
.pow.pow canvas is scrolled and the "Post" form will fire *after*.
Combinations of the two should hopefully allow any custom behaviors
you want.

POW has general canvas and/or image bindings for changing the
colortable of an image and for dragging out a Region of Interest
(ROI).  By default, these are bound to B1 and B3 respectively (on 2
button mice under Windows these are the two available buttons).  If
you need to move these bindings to other buttons (to make way for your
application's own behavior) you can set $powLutButton or $powROIButton
to a different number after loading libpow.so but before calling
powInit.  You can also disable either function entirely by setting 
the corresponding variable to "0" or "NULL". For example, to move
colortable "diddling" to button 2 and disable ROI dragging do:

load libpow.so
set powLutButton "2"
set powROIButton "0"
powInit .someWindow


powGraphToCanvas graph x y ?canvas? -  takes physical coordinates
             and returns a two element list giving the corresponding position
	     on the specified canvas (.pow.pow by default).

powCanvasToGraph graph x y ?canvas? - takes a canvas coordinate 
             and returns the corresponding physical coordinates.
             Optional argument specifies the canvas (.pow.pow by default). 

powWhereAmI x y - takes an (x,y) pair of canvas coordinates and returns
             which graph (or subgraph) they are inside of. If they are outside
             of all graphs, returns "NULL".

powFindCurvesMinMax curves X|Y|Z - takes a list of curves and an axis 
            (X,Y, or Z) and returns the minimum and maximum values.


Provided Interface Routines

There will be more of these as I get feedback on what people need/want.

powDragRange X|Y tag color callback - This will set up a binding on the
left mouse button so that the user can click and drag a range in either
Y or X for the *selected graph*.  He will see a line joining the current
cursor position and the start position.  When he releases the LMB, all
of the graph points that fall in the selected range will be tagged
with the "tag" argument and will appear with the chosen "color".  The
"callback" routine will be called with arguments graphname, X0 and X1 
(or Y0 and Y1), specifying the edges of the user selected range in 
*graph* (i.e. physical) coordinates.  To remove a  previous selection,
just execute the Tk commands: 
".pow.pow itemconfigure $tag -fill black; .pow.pow delete $tag" 

This could be used to implement an "undo" feature.
powDragRange will also select the congruent range on all graphs with axes
linked to the chosen axis in the current graph.

powDragRect tag color callback -  This works the same as powDragRange, but
the user chooses a rectangular region of the selected graph.  And the
callback routine recieves 5 arguments (graphname X0 Y0 X1 Y1). Also, 
powDragRect ignores linked axes because it's not clear what "should"
happen to the unlinked axis. If someone wants to make a case for a
different (or selectable) behavior here, feel free.

Linked Axes

POW allows you to "link" any number of axes on different graphs together.
The resulting set of linked axes is called a "chain".  Each axis can only
be a member of one chain.  Linking an axis from one chain to an axis in 
another chain has the effect of merging the two chains.  Zooming on a
region of interest on one graph will affect the linked axis on any other
graph.  There are several utility routines.  Also, the GUI allows the
user to view links as light pink lines connecting linked axes.

powLinkAxes graph1 axis1 graph2 axis2 - The axis can be specified with a
            capital 'X' or 'Y'.

powBreakLink graph axis - removes the specified axis from its chain.

powAlignChain graph axis orientation ?gap? - orientation can be H 
	(for horizontal) or V (for vertical).  This routine will move
	all graphs belonging to the same chain as the specified graph 
	so that they are aligned on the canvas.  I.e.  it "stacks" the
	graphs up in a column or lines them up in a row on the users screen.
	The optional "gap" argument determines how much blank space (in 
	pixels to leave between graphs).



"Useful Stuff that should be safe to access"

The name of the pow canvas is ".pow.pow"

The tag for the axis box for a graph is:
${graphname}box
When multi-axes are done, it will be:
$graphname$xunits${yunits}box

Everything belonging to a graph is tagged with the graph name.





Do bugs still exist.  You bet!  Still too many to make a list yet, really; 
you'll know 'em when you see 'em.  Known bugs in the latest release are
listed on the "fv known bugs list" web page: 

        http://heasarc.gsfc.nasa.gov/ftools/fv/fv_bugs.html


Some info on the FitsTcl functions:


I checked in the new fitstcl with the function you need to load a column
 in a table into memory.

Usage : FitsObj load column $colName $nulValue
	where  	colName - column name
	 	nulValue - the default Null value you want to set

it returns "$address $dataType $numElements"
	where 	(1) data can be recovered by "sscanf(address, "%p", &databuff)
			with void *databuff
	        (2) dataType 0 - byte
			     1 - int
	 		     2 - long
		             3 - float
	 		     4 - double
	       	(3) numElement : size of the array

Thanks

Jianjun



C Interface:

All of the functions do the same thing as their TCL counterparts.  I'll
list the definitions below.  The parallels should be obvious.  The one
thing you will need is an event handler (i.e., when you call Pow, your
program has to stop and let the user play with his or her graph).  To 
do this you call an Event Handler.  When the user activates the "Close Pow"
button, control returns to your program.  Eventually you'll be able
to fork off the Event Handler etc., but for now, this is it.

Only the "Constructors" are available from C, for now.  All of the "Methods"
are written in TCL, so rather than creating Oroburos code with C calls
TCL calls C calls ..., if you want to use any of them, just call

Tcl_VarEval(proc,argument,argument,...,NULL);  - Note: all arguments
                                                 are STRINGS ! 

(see Ousterhout for details). 


Event Handlers

void PowHandleEvents( )  Your program stops, when the user closes POW
                         your program begins again.

void PowWishHandleEvents( ) Your program stops, until the user closes the POW
                            GUI she can type in TCL commands at a wish
                            prompt.  Useful for debugging and probably
                            in production code as well. When the user closes
                            POW, your program begins again.

"Constructors"

All of the POW functions have a status argument rather than just returning 
the status.  Yes I know it's awkward, but it makes FORTRAN happier, of course
noone's actually calling it from FORTRAN, but it was in the requirements....


void PowInit(char *powSetupColormapArgs, char *powInitArgs, int *status)  - 
      Call this before calling any other POW functions.  PowInit first calls
      the general POW initialization routine (in the TCL version, this gets
      called when you load libpow.so).  Then it calls powSetupColormap if
      you've specified anything in the powSetupColormapArgs argument.  Then
      it calls the TCL proc powInit with any powInitArgs you've specified.
      See above for descriptions of how powSetupColormap and powInit work.
	Example:  To force truecolor when you have no additional windows
                  to create and your application will be using no more than
                  10 non-POW colors do:

        PowInit(".dummy 10 2",".dummy ",&status);

        Tcl_VarEval(interp,"wm withdraw .dummy",(char *)NULL);



void PowCreateData(char *data_name, void *data_array, int *data_type,
		   int *length, int *copy, int *status) 


void PowCreateVector(char *vector_name, char *data_name, int *offset,
		     int *length, char *units, int *status) 

void PowCreateVectorEN(char *vector_name, char *data_name, 
			     int *length, double *start, double *increment, 
			     char *units, int *status) 

void PowCreateImage(char *image_name,char *data_name, int *xoffset, 
		    int *yoffset, int *width, int *height, double *xorigin, 
		    double *xinc, double *yorigin, double *yinc,char *xunits,
		    char *yunits, char *zunits, int *status)

void PowCreateCurve(char *curve_name, char *x_vector, char *x_error,
		    char *y_vector, char *y_error, char *z_vector, 
		    char *z_error, int *status)

void PowCreateGraph(char *graph_name, char *curves, char *images,
		    char *xunits, char *yunits, char *xlabel, char *ylabel,
		    int *xdimdisp, int *ydimdisp, double *xmin_in, 
		    double *ymin_in, double *xmax_in, double *ymax_in, 
		    int *status)




Pages maintained by Bryan Irby
Send bug reports or feature requests via the FTOOLS help desk.

HEASARC Home | Observatories | Archive | Calibration | Software | Tools | Students/Teachers/Public

Last modified: Tuesday, 01-Aug-2006 14:44:00 EDT

HEASARC Staff Scientist Position - Applications are now being accepted for a Staff Scientist with significant experience and interest in the technical aspects of astrophysics research, to work in the High Energy Astrophysics Science Archive Research Center (HEASARC) at NASA Goddard Space Flight Center (GSFC) in Greenbelt, MD. Refer to the AAS Job register for full details.