envbvs@epb2.lbl.gov (Brian V. Smith) (03/09/90)
Certain command-line options for xfig that used to work aren't
parsed correctly any more on a Sun 4 with Sunos 4.0 and X11R4.
Things worked correctly under R3, and they still work on a Vaxstation
running Ultrix and X11R4.
The two options that don't have any effect any more are -portrait
and -notrack.
Here is the relevant information and code from main.c:
extern int DEBUG;
extern int RHS_PANEL;
extern int INVERSE;
extern int TRACKING;
extern int landscape;
Widget tool;
int WINDOW_WIDTH, WINDOW_HEIGHT;
static int true = True;
static int false = False;
static int zero = 0;
static float tmp_width = 0.0, tmp_height = 0.0;
static XtResource application_resources[] = {
{XtNjustify, XtCJustify, XtRBoolean, sizeof(int),
(Cardinal)&RHS_PANEL, XtRBoolean, (caddr_t)&false},
{"debug", "Debug", XtRBoolean, sizeof(int),
(Cardinal)&DEBUG, XtRBoolean, (caddr_t)&false},
{"landscape", XtCOrientation, XtRBoolean, sizeof(int),
(Cardinal)&landscape, XtRBoolean, (caddr_t)&true},
{XtNwidth, XtCWidth, XtRFloat, sizeof(float),
(Cardinal)&tmp_width, XtRInt, (caddr_t)&zero},
{XtNheight, XtCHeight, XtRFloat, sizeof(float),
(Cardinal)&tmp_height, XtRInt, (caddr_t)&zero},
{XtNreverseVideo, XtCReverseVideo, XtRBoolean, sizeof(int),
(Cardinal)&INVERSE, XtRBoolean, (caddr_t)&false},
{"trackCursor", "Track", XtRBoolean, sizeof(int),
(Cardinal)&TRACKING, XtRBoolean, (caddr_t)&false},
{"inches", "Inches", XtRBoolean, sizeof(int),
(Cardinal)&INCHES, XtRBoolean, (caddr_t)&true},
{"boldFont", "BoldFont", XtRString, sizeof(caddr_t),
(Cardinal)&boldFont, XtRString, (caddr_t)NULL},
{"normalFont", "NormalFont", XtRString, sizeof(caddr_t),
(Cardinal)&normalFont, XtRString, (caddr_t)NULL},
};
static XrmOptionDescRec options[] =
{
{"-right", ".justify", XrmoptionNoArg, "True" },
{"-left", ".justify", XrmoptionNoArg, "False"},
{"-debug", ".debug", XrmoptionNoArg, "True"},
{"-landscape", ".landscape", XrmoptionNoArg, "True"},
{"-Landscape", ".landscape", XrmoptionNoArg, "True"},
{"-portrait", ".landscape", XrmoptionNoArg, "False"},
{"-Portrait", ".landscape", XrmoptionNoArg, "False"},
{"-width", ".width", XrmoptionSepArg, 0},
{"-height", ".height", XrmoptionSepArg, 0},
{"-inverse", ".reverseVideo", XrmoptionNoArg, "True"},
{"-notrack", ".trackCursor", XrmoptionNoArg, "False"},
{"-track", ".trackCursor", XrmoptionNoArg, "True"},
{"-inches", ".inches", XrmoptionNoArg, "True"},
{"-imperial", ".inches", XrmoptionNoArg, "True"},
{"-centimeters", ".inches", XrmoptionNoArg, "False"},
{"-metric", ".inches", XrmoptionNoArg, "False"},
{"-boldFont", ".boldFont", XrmoptionSepArg, 0},
{"-normalFont", ".normalFont", XrmoptionSepArg, 0},
};
main(argc,argv)
char *argc;
int *argv[];
{
tool = XtInitialize("fig", "Fig", options, XtNumber(options),
&argc, argv);
XtAddConverter("String", "Float", CvtStringToFloat, NULL, 0);
XtAddConverter("Int", "Float", CvtIntToFloat, NULL, 0);
XtGetApplicationResources(tool, 0, application_resources,
XtNumber(application_resources), NULL, 0 );
if (argc > 1)
file = argv[1];
When starting xfig with -landscape, after the call to
XtGetApplicationResources, dbx shows that landscape = 1 instead of 0(False).
Is this a known bug in XtGetApplicationResources?
All of the other options work fine except -notrack.
_____________________________________
Brian V. Smith (bvsmith@lbl.gov)
Lawrence Berkeley Laboratory
I don't speak for LBL, these non-opinions are all mine.envbvs@epb2.lbl.gov (Brian V. Smith) (03/13/90)
There seems to be a bug in XtGetApplicationResources that appears
on Sun4's (4.0) but not on Vaxstations (Ultrix 3.0) or DECstation 3100
(Worksystem V2.0, which I believe is Ultrix 3.0). All are using R4 from
MIT (installed by me).
Compile with -lXt -lX11
The bug is that some resources are parsed correctly and one in particular
is not. Here is a whole program which demonstrates the point.
Run with -portrait or -P and the landscape variable should be set to 0.
This one doesn't work on a sun4.
Run with -right and justify should be set to 1. It sets justify to 16777216
instead, which is 1000000 hex (byte order problem?)
I am mailing to xbugs, but if anyone has any ideas, I would appreciate it.
_____________________________________
Brian V. Smith (bvsmith@lbl.gov)
Lawrence Berkeley Laboratory
I don't speak for LBL, these non-opinions are all mine.
-------------------- program is here ----------------------
#include <stdio.h>
#include <X11/Intrinsic.h>
#include <X11/StringDefs.h>
static int true = True;
static int false = False;
int landscape = 1;
int RHS_PANEL = 0;
static XtResource application_resources[] = {
{XtNjustify, XtCJustify, XtRBoolean, sizeof(int),
(Cardinal)&RHS_PANEL, XtRBoolean, (caddr_t)&false},
{"landscape", XtCOrientation, XtRBoolean, sizeof(int),
(Cardinal)&landscape, XtRBoolean, (caddr_t)&true},
};
static XrmOptionDescRec options[] =
{
{"-right", ".justify", XrmoptionNoArg, "True" },
{"-portrait", ".landscape", XrmoptionNoArg, "False"},
};
main(argc,argv)
int argc;
char *argv[];
{
Widget tool;
tool = XtInitialize("fig", "Fig", options, XtNumber(options),
&argc, argv);
XtGetApplicationResources(tool, 0, application_resources,
XtNumber(application_resources), NULL, 0 );
fprintf(stderr,"landscape = %d, justify = %d\n",landscape,RHS_PANEL);
}envbvs@epb2.lbl.gov (Brian V. Smith) (03/13/90)
I just posted info about a bug in XtGetApplicationResources, to which
I have found a "solution".
The problem was that I had initialized my "landscape" variable to 1
before calling XtGetApplicationResources and that was preventing
it (somehow) from setting it to 0 when I gave the -portrait option.
If the variable starts as 0 then everything is fine, i.e. if the
user specifies -portrait then landscape = 0, and if -portrait is NOT
specified landscape = 1.
Why does it matter if the variable has a non-zero value to start?
Again, this is only a problem on a sun4 (running sunos4.0) and not
a problem on a Vaxstation (Ultrix 3.0) or DECstation 3100 (Ultrix 3.0)
Here is the program again:
#include <stdio.h>
#include <X11/Intrinsic.h>
#include <X11/StringDefs.h>
static int true = True;
static int false = False;
int landscape = 1; /****** PROBLEM BECAUSE OF THIS *****/
int RHS_PANEL = 0;
static XtResource application_resources[] = {
{XtNjustify, XtCJustify, XtRBoolean, sizeof(int),
(Cardinal)&RHS_PANEL, XtRBoolean, (caddr_t)&false},
{"landscape", XtCOrientation, XtRBoolean, sizeof(int),
(Cardinal)&landscape, XtRBoolean, (caddr_t)&true},
};
static XrmOptionDescRec options[] =
{
{"-right", ".justify", XrmoptionNoArg, "True" },
{"-portrait", ".landscape", XrmoptionNoArg, "False"},
};
main(argc,argv)
int argc;
char *argv[];
{
Widget tool;
tool = XtInitialize("fig", "Fig", options, XtNumber(options),
&argc, argv);
XtGetApplicationResources(tool, 0, application_resources,
XtNumber(application_resources), NULL, 0 );
fprintf(stderr,"landscape = %d, justify = %d\n",landscape,RHS_PANEL);
}
_____________________________________
Brian V. Smith (bvsmith@lbl.gov)
Lawrence Berkeley Laboratory
I don't speak for LBL, these non-opinions are all mine.mikey@wsl.dec.com (Mike Yang) (03/13/90)
In article <5062@helios.ee.lbl.gov>, envbvs@epb2.lbl.gov (Brian V. Smith) writes: > Why does it matter if the variable has a non-zero value to start? > Again, this is only a problem on a sun4 (running sunos4.0) and not > a problem on a Vaxstation (Ultrix 3.0) or DECstation 3100 (Ultrix 3.0) > > ... > > static XtResource application_resources[] = { > {XtNjustify, XtCJustify, XtRBoolean, sizeof(int), > (Cardinal)&RHS_PANEL, XtRBoolean, (caddr_t)&false}, > {"landscape", XtCOrientation, XtRBoolean, sizeof(int), > (Cardinal)&landscape, XtRBoolean, (caddr_t)&true}, > }; From the Intrinsics manual, "The resource_size field is the size of the physical representation in bytes; you should specify it as "sizeof(type)" so that the compiler fills in the value." Therefore, you should instead have: {"landscape", XtCOrientation, XtRBoolean, sizeof(Boolean), (Cardinal)&landscape, XtRBoolean, (caddr_t)&true}, The difference in sizes between Boolean, typedef'd to char, and int varies among machines and this probably made things work under Ultrix but not on your Sun. ----------------------------------------------------------------------------- Mike Yang Western Software Laboratory Digital Equipment Corporation mikey@wsl.dec.com decwrl!mikey 415/853-6677
asente@decwrl.dec.com (Paul Asente) (03/13/90)
In article <5062@helios.ee.lbl.gov> envbvs@epb2.lbl.gov (Brian V. Smith) writes: >int landscape = 1; /****** PROBLEM BECAUSE OF THIS *****/ >int RHS_PANEL = 0; > >static XtResource application_resources[] = { > {XtNjustify, XtCJustify, XtRBoolean, sizeof(int), > (Cardinal)&RHS_PANEL, XtRBoolean, (caddr_t)&false}, > {"landscape", XtCOrientation, XtRBoolean, sizeof(int), > (Cardinal)&landscape, XtRBoolean, (caddr_t)&true}, >}; This is horribly nonportable and may be your problem. The offset field, a Cardinal, is an unsigned int of at least 16 bits. There's no guarantee that you can store an address into a Cardinal value without losing bits or having weird sign extension problems. You should have struct _appres { int landscape; int RHS_PANEL; } appres; static XtResource application_resources[] = { {XtNjustify, XtCJustify, XtRInt, sizeof(int), XtOffset((struct _appres *), RHS_PANEL), XtRInt, (caddr_t)&false}, ... And you pass &appres to XtGetApplicationResources as the base. Notice that I also changed the XtRBooleans to XtRInts to match the data declarations. Either or both of these could be your problem. -paul asente asente@decwrl.dec.com decwrl!asente