# Programming Tips

This is a start at a list of programming tips for Motif - not LessTif specific. It's not intended to be a comprehensive guide, but rather a collection of useful techniques that are often overlooked and can really speed Motif development and execution of Motif programs.

Since it's so short at the moment, there's not much in the way of overall organization, but as the list grows, we'll fix that.

1. What's the preferred way to specify arguments (i.e. XtSetArg, etc)?
   There are two answers to this question depending on if the resources actually need to be specified before/during creation, or if they can be specified after creation. For resources which must be set prior to creation, the preferred method is this:

           int n;
           Arg args[10];
           Widget button;

           n=0;
           XtSetArg(args[n], XmNx, 100); n++;
           XtSetArg(args[n], XmNy, 120); n++;
           button = XmCreatePushButton(parent, "Button", args, n);

   The advantage of this is that you don't have to keep count of the arguments yourself, which is prone to error. Note that you can't use args[n++] because this is a macro which will be expanded to have more than one n++ in it. A disadvantage to this is that you may overflow your static args array if you add to many args. Fortunately, when this happens it almost always causes immediate problems (i.e. a core dump) which means that the error will usually be caught fairly quickly. For resources which may be set after creation, the preferred method as follows:

           button = XmCreatePushButton(parent, "Button", NULL, 0);
           XtVaSetValues(button,
        	          XmNx, 100,
                 	  XmNy, 120,
       	          NULL);

   This eliminates any possibility of overflowing the Arg array, and is easier to type and read anyway. This method should be used for all resources except those which must be set during widget creation.

2. When should widgets be managed?
   Manager widgets should not be managed until *after* all the children are added. This is because geometry calculations are expensive operations (timewise) and if the manager widget is managed it must re-negotiate the geometry of all its children after each new child is added, instead of doing it only once after all children are added.