[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:STAR::VATNE
Created:Mon Oct 30 1989
Last Modified:Mon Dec 31 1990
Last Successful Update:Fri Jun 06 1997
Number of topics:3726
Total number of notes:19516

2649.0. "Does order matter for XtSetArg with XtSetValues?" by FREZEN::PROJECTS () Tue Apr 24 1990 15:02

I know that XtSetarg sets up an argument list and prepares it to be passed to
XtSetValues.
I know that XtSetvalues in some manner goes thru a loop for num args and calls 
the widget's SetValues routine with setting each argument.


(1) In what order does XtSetvalues do this?

(2) Can I write code to do a certain thing (in the widget) hoping that the 
    argument my code (in the widget) depends on has been set?

(3) If I can't depend on arguments being set is there a way to pass args by
    descriptor?


Greatly appreciated
T.RTitleUserPersonal
Name
DateLines
2649.1determined by the widget...R2ME2::OBRYANWhen in doubt, let the user decide.Tue Apr 24 1990 18:428
re:.0

>             -< Does order matter for XtSetArg with XtSetValues? >-

The widget's SetValues-processing routine determines the order in which each
SetValued argument is processed... the order in which you specified the
arguments in the Arg list is (typically) irrelevant.
2649.2FREZEN::PROJECTSTue Apr 24 1990 19:5712
re. 1

If you don't mind me asking... How does the widget's  SetValues-processing
routine determine this sequence.

The SetValues routine I have created for my widget coincides with what has
been documented in the manuals to a great extent. I see no indications in
the examples of the widget's  SetValues-processing routine determining the
set sequence of the argument list.

Could you expand a little more?
Thanks
2649.3getting closer?R2ME2::OBRYANWhen in doubt, let the user decide.Wed Apr 25 1990 12:3220
re:.2

   When a calling application calls XtSetValues on a widget, the intrinsics
is in charge of processing the (entire) arg list, populating a new widget
instance with the values specified in that list.  The widget is then in charge
of making any special arrangements to respond to the new values in the new
widget instance record (handled by the widget's SetValues routine.)  Since the
widget does not see the caller's arg list, the order of appearance of values
in the arg list is irrelevant to the widget.  The widget, by scanning the
new widget instance field-by-field, determines the effective "order of
processing" of the caller's supplied args.

   After rereading your original note, I'm getting the impression that you
are expecting the widget's SetValues routine to be called once for each
argument in the arg list... this is not the case (as explained above).
Have I misunderstood your base note?  (My response in .1 was only to address
question #1.  I don't understand questions #2 and 3.)

Michael
2649.4FREZEN::PROJECTSWed Apr 25 1990 12:4522
>After rereading your original note, I'm getting the impression that you
>are expecting the widget's SetValues routine to be called once for each
>argument in the arg list... 

I have been told that the widget is called each time for each Arg on the list.

>The widget, by scanning the new widget instance field-by-field, determines the
>effective "order of processing" of the caller's supplied args.

How can I do this? All I see as parms to my setvalues are

	static Boolean SetValues(old, request, new)

which are of my subclass struct type.

I don't mean to be ignorant... I just can't grasp how you can scan the new 
widget instance (what is that? where is it? what struct is it?). I also don't
see how I can determine the effective order of processing by looking at the
fields of the widget instance record. What fields indicate this order?

Much appreciated
Ken
2649.5DoSetValuesDECWIN::JMSYNGEJames M Synge, VMS DevelopmentWed Apr 25 1990 14:1450
    >I have been told that the widget is called each time for each Arg on
    >the list.
    
    I don't believe that is correct.  XtSetValues creates two copies of
    your widget record (oldW and refW in the example below).  The first
    argument to your widget's setvalues routine is a COPY of your widget
    record with the values it had before any changes were made.  The second
    argument is a COPY of your widget, with all the changes applied.  And
    (if I understand correctly) the third argument IS your widget, with the
    changes applied, after your widget's ancestors in the class hierarchy
    have had a chance to make any changes they wanted to.
    
    I've included a copy of one of a widget's setvalues routine as an
    example of handling multiple changes:
    
    
    
#define Changed(f) (w->f != oldW->f)

static int DoSetValues(oldW, refW, w)
    VIconWidget oldW, refW, w;
{
	if (Changed(label_widget))
		AmendLabelWidget(w);

	if (Changed(core.background_pixmap)) {
		w->normal_pixmap = w->core.background_pixmap;

		if (w->highlighted)
			/* The 'wrong' pixmap got changed. */
			w->core.background_pixmap = w->highlight_pixmap;
	}

	if (Changed(highlight_pixmap))
		if (w->highlighted)
			w->core.background_pixmap = w->highlight_pixmap;

	if (!XtIsRealized (w)) return 0;

	if (Changed(core.background_pixmap))
		SetWidgetBackgroundPixmap(w, w->core.background_pixmap, True);

	if (Changed(core.x) | Changed(core.y) |
	    Changed(core.width) | Changed(core.height) |
	    Changed(label_widget) | Changed(label_alignment)) {

		CenterLabel(w);
	}
}
    
2649.6XtSetValues is superclass -> subclass chainedLEOVAX::TREGGIARIThu Apr 26 1990 09:2015
    .5 is correct.  The only point I'd like to expand upon is that the
    SetValues method is "Chained" from superclass to subclass.  That
    is, when XtSetValues is called on your widget, the SetValues method
    of all of your widget's superclasses are called before your SetValues
    method is called.  So, for the most part, you only need to worry
    about changes to the fields within your own instance part (although
    sometimes changes to fields within your superclasses need to be
    examined).  That is why .5 said:
    
    "the third argument IS your widget, with the
     changes applied, after your widget's ancestors in the class hierarchy
     have had a chance to make any changes they wanted to."
                                
    Leo