Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!sun-barr!newstop!sun!argv
From: argv@turnpike.Eng.Sun.COM (Dan Heller)
Newsgroups: comp.windows.x.motif
Subject: Re: XmLabel question
Message-ID: <141712@sun.Eng.Sun.COM>
Date: 31 Aug 90 22:54:51 GMT
References: <118526@linus.mitre.org>
Sender: news@sun.Eng.Sun.COM
Organization: O'Reilly && Associates
Lines: 73

In article <118526@linus.mitre.org> daf@mbunix.mitre.org (Dennis Franciskovich) writes:
>   For example, I've
> been using the following function call:
> XmCreateLabel(parent, "label string", NULL, 0);
> This works fine with no apparent problem.  My question is, is this a
> bad thing to do?

It depends on how you want to utilize (or make available) the ability
for the user to configure the user interface.  This particular issue
is important because it addresses all widgets of your program.  To answer
your question directly: "no, it's not a 'bad' thing."  And I say that
because my definition of "bad" is a practice that is inefficient, difficult
to maintain, or counter-productive.  There -are- better methods, but that
doesn't imply that this is a "bad" method.  Because you are using the name
of the widget itself as the label, the user's resource file would specify
attributes about the widget using the label's name:

    *label string.labelString: another label

This means: all widgets that have the name "label string" should use a
label string that says: "another label".  This is true because you did
*not* set the resource XmNlabelString to be some value in the call to
XmCreateLabel():

    XmString string = XmStringCreateLtoR("another label", charset);
    XtSetArg(args[0], XmLabelString, string);
    XmCreateLabel(parent, "label string", args, 1);
    XmStringFree(string);

Here, the label string is "hard-coded" and cannot be changed by resources
at all.  Thus, the previous resource specification won't work.  This may or
may not be what you want!  Don't let people tell you this is a "bad thing."
There are certainly very good reasons for *not* doing this -- but there
are equally good reasons *for* doing this.  You have to ultimately decide
whether or not you want the user or system admins to be able to change the
labels on your widgets.

Another thing to consider is the fact that to hard-code the label, you have
to create a compound string (which allocates memory) and then free it.
If you are doing this for hundreds of labels (which isn't uncommon),
then you're going to fragment your heap space pretty quickly and lower
your performance ratio.

Footnote: Probably a good enhancement for Motif 1.1.1 would be a routine
that created and returned a pointer to a compound string that was stored
in static space.  Each call would overwrite the contents of the previous
call -- that way, you can use strings that are temporary all over the 
place without all that overhead of allocating and deallocating memory.
Either that, or provide a string conversion function that puts the new
string in pre-allocated space (so the programmer can provide the same
buffer all the time).

> This is related to another discovery I made:
> I accidentally left out the last two arguments,
> 
> XmCreateLabel(parent, "label string");
> 
> and this also worked with no error at either compilation or run time.

The remaining arguments to the function are literally "garbage" values.
That is, it is completely undefined as to what got pushed onto the stack
at the time that XmCreateLabel() got called.  In short, "you got lucky".
The reason you didn't get a core dump is speculative, but I'm guessing
your program was short and most of what was on the stack was already set
to zeros -- it appeared to XmCreateLabel() that you had passed a NULL and
a 0 as the missing args.  Longer programs will show that this won't work
as conveniently.

--
dan
----------------------------------------------------
O'Reilly && Associates   argv@sun.com / argv@ora.com
Opinions expressed reflect those of the author only.