Conference bulova::decw_jan-89_to_nov-90

You didn't mention what type of widget this is, and if it is not an XUI
widget what its superclass is.  I can't answer the question definitely without
this information.  But, in general, widgets do redisplay on a change in
sensitivity because they "gray" themselves out.

Leo

  Thanks for the reply Leo, the customer is using his own widget but gave me
an example where the widget is a XUI Window widget.

  Do you know if there is any documentation to explain which attribute
changes would cause set_values to return TRUE. Could you have your own
set_values function instead of the one provided ?

  I don't know what his widget's superclass is. He's got a large
application and I've asked him to reproduce his problem outside of this
application. He views this functionality as a problem with our software. I'm
trying to prove that the way it is working IS conforming to the X standard
and therefore we don't consider it a problem. The DEC documentation does
not seem to go into detail with X Toolkit Intrinsics.



Here is the code that the customer supplied me with :-


#include "decw$include:dwtappl.h"

globaldef int g_appc;
globaldef int g_screen_width;
globaldef int g_screen_height;
globaldef Display *g_display;

globaldef int g_app_shell;

void expose_callback();

main (argc, argv)
int argc;
char *argv[];

{
char *dum_argv[1];
int dum_argc = 0;
int i = 20;
Arg arglist[2];
char *display_str = NULL;
char *display_str2;
Widget popup_shell_xid,main_window_xid,dialog_box_xid,window_xid;
int count;
XEvent event;
DwtCallback callback_arg[2];
Window win;
long event_mask;

XtToolkitInitialize();

g_appc = XtCreateApplicationContext();

if ((g_display = XtOpenDisplay(g_appc, display_str, "FIST disp name",
		"disp classes", NULL, 0, &dum_argc, dum_argv)) == NULL)
	{
	printf ("XtOpenDisplay failed to open display\n");
	}

XSynchronize(g_display,1);

g_app_shell = XtAppCreateShell("FIST and X windows",
				"toplevelclass",
				applicationShellWidgetClass,
				g_display,
				NULL,
				0 );
popup_shell_xid = XtCreatePopupShell ( "test",
					applicationShellWidgetClass,
					g_app_shell,
					NULL,
					NULL );
main_window_xid = DwtMainWindow (popup_shell_xid,
				"FIST",
				0,0,0,0 );
dialog_box_xid = DwtDialogBox (main_window_xid,
				"dialog_box",
				TRUE,
				0,0,0,
				DwtWorkarea,
				0,0);
DwtMainSetAreas (main_window_xid,
		NULL,
		dialog_box_xid,
		NULL,
		NULL,
		NULL);

XtSetArg(arglist[0], DwtNx, 0 );
XtSetArg(arglist[1], DwtNy, 0 );
XtSetArg(arglist[2], DwtNwidth, 200 );
XtSetArg(arglist[3], DwtNheight, 200 );
window_xid = DwtWindowCreate (dialog_box_xid,
			"window, widget",
			arglist, 4 );

XtManageChild(window_xid);
XtManageChild(dialog_box_xid);
XtManageChild(main_window_xid);
XtManageChild(popup_shell_xid);

XtPopup(popup_shell_xid, NULL);
event_mask = 0xFFFFFFFF;
win = XtWindow (main_window_xid);
printf("\nwindow id = %d", win);
XSelectInput(g_display, win, event_mask);

callback_arg[0].proc = expose_callback;
callback_arg[0].tag = NULL;
callback_arg[1].proc = NULL;
callback_arg[1].tag = NULL;

XtSetArg(arglist[0], DwtNexposeCallback, callback_arg );
XtSetValues(window_xid, arglist, 1 );

count = 5;
for (;;)
	{
	XtAppNextEvent(g_appc, &event);
	printf ("\n%d",event.type);

/*
	if (event.type == Expose)
		printf("\nExpose event");

	if (--count == 0)
		{
		count = 5;
		printf ("calling Set Values\n");
		XtSetArg(arglist[0], DwtNy, i );
		XtSetValues(window_xid, arglist, 1 );
		}
	i = i + 20;
*/
	XtDispatchEvent(&event);
	}

}/*main*/

void expose_callback(widget_id, tag, callback_data )
Widget *widget_id;
Opaque tag;
DwtWindowCallbackStruct *callback_data;

{
printf("expose callback called for the window widget\n");
printf (" - (%d,%d), width %d, height %d, count %d\n",
		callback_data->event->x, callback_data->event->y,
		callback_data->event->width, callback_data->event->height,
		callback_data->event->count);
}

There is a bug in the dialog box widget class (and its subclasses) that is:

	If the dialog box units is FontUnits (as opposed to PixelUnits),
	then the ConstraintSetValues routine in the dialog widget class
	ALWAYS forces a redisplay on any SetValues of one of its children.

This has been reported and may already be fixed for DECwindows V3, but
I haven't checked.

What this means is that the dialog box must use PixelUnits instead of
FontUnits.

Hope this helps.  If it doesn't work, let us know.

-steve-

>  Do you know if there is any documentation to explain which attribute
> changes would cause set_values to return TRUE. 

No, it isn't documented anywhere.

> Could you have your own
> set_values function instead of the one provided ?

Not legally.  The Intrinsics define class records as read-only after
the class has been initialized.

> He views this functionality as a problem with our software. I'm
> trying to prove that the way it is working IS conforming to the X standard
> and therefore we don't consider it a problem.

If the widget displays correctly, it is conforming to the X standard.
That is, there are no rules on when a SetValues routine should return
redisplay other than to make sure that it displays itself correctly.
A SetValues routine that always returns True would "conform".

Of course, it may be undersirable from a performance point of view if
it does it unnecessarily.

Leo

I can't tell from the test program what is supposed to happen.

But I really think that the problem is that the dialog box is using
(by default) FontUnits and the user will need to specify PixelUnits
to get around the dialog box bug.

Please let us know if this is the problem.

-steve-

>I can't tell from the test program what is supposed to happen.

  Neither could I Steve 'till I asked the guy, all it shows is that expose
events are returned every time a 'set values' is performed.

  The 'PixelUnits' work around seems to work for him, although I don't
know if he's entirely happy. He has reported quite a few problems to me
recently which I'm trying to validate, so I think unless I hear different,
I'll consider this problem solved for the time being. Thanks for the info,
I'll keep you posted.

				-/-

  Thanks for the other answers Leo, can you recommend any good books
on X that maybe worth getting, we've just got a set published by O'Reilly
& Associates Inc. which seem to be very readable.

Richard

>  Thanks for the other answers Leo, can you recommend any good books
> on X that maybe worth getting, we've just got a set published by O'Reilly
> & Associates Inc. which seem to be very readable.

    When I learned X, there were only the specs, so that is what I stick to.
    If they are interested in what is "conforming" and what is not, they
    should get the Intrinsics spec and the Xlib book by Scheifler, Gettys,
    ...
    
    Leo