[Xastir] Print and/or screen dump

[Curt, WE7U]

On Tue, 28 Dec 2004, Tom Russo wrote:

> On Tue, Dec 28, 2004 at 01:35:04AM -0500, we recorded a bogon-computron collision of the <kd1yv at arrl.net> flavor, containing:
> > Tom Russo wrote:
>
> If instead you were to add an "int xpmretval;" at around line 2096 (up where
> the other variable declarations are), and do:
>
>    xpmretval=XpmWriteFileFromPixmap(XtDisplay(appshell),   // Display *display
>             xpm_filename,                               // char *filename
>             pixmap_final,                               // Pixmap pixmap
>             (Pixmap)NULL,                               // Pixmap shapemask
>             NULL );
>    if (xpmretval != XpmSuccess) {
>        fprintf(stderr,"ERROR %d writing %s\n", xpmretval, xpm_filename );
>     }
>
> you'd get some more information.  Look in /usr/X11R6/include/X11/xpm.h (or
> wherever your xpm.h lives) --- you'll see a set of possible return values.
> Mine has:
>
> #define XpmColorError    1
> #define XpmSuccess       0
> #define XpmOpenFailed   -1
> #define XpmFileInvalid  -2
> #define XpmNoMemory     -3
> #define XpmColorFailed  -4
>
> Given the return value in the fprintf, you'd be able to see why it says it's
> failing.  That might not tell you how to make it succeed, but if it's
> OpenFailed or FileInvalid it might point the way.  If it's ColorError, NoMemory
> or ColorFailed I don't know how to fix it.

If you think the Xpm define's might be somewhat uniform across
platforms, we could put in code that spits out the text to go along
with the integers.  If not, perhaps we could just dump out the int
itself like you have above.  No matter what it's good to tell the
user more.


> I'm thinking that perhaps this change is something that should be in the code
> anyway --- the write function reports why it fails, we should probably
> toss the user a bone and tell what we can about the nature of the failure.

Yep.  Please add at least the code listed above, or I can.


> Obvious (too obvious) other things to look at: does the exact directory
> that is reported in the error message actually exist?  Is there a print.xpm
> file in there that doesn't allow you to overwrite it?  Is there enough disk
> space to allow the file to be created?  Like I said, these are really obvious
> things, but one has to grasp at straws sometimes.

A return value of -1 would be a big hint in these cases.  I'm not
exactly sure what -2 would indicate, perhaps that there's a file
there but we can't overwrite it?

--
Curt, WE7U.   APRS Client Comparisons: http://www.eskimo.com/~archer
"Lotto:    A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"