Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!samsung!sol.ctr.columbia.edu!emory!gatech!uflorida!mlb.semi.harris.com!trantor.harris-atd.com!trantor!chuck
From: chuck@trantor.harris-atd.com (Chuck Musciano)
Newsgroups: comp.windows.open-look
Subject: Re: XView Programming Style
Message-ID: <5953@trantor.harris-atd.com>
Date: 29 Mar 91 12:47:30 GMT
References: <0x6u9ws@openlook.Unify.Com> <971@elan.Elan.COM>
Sender: news@trantor.harris-atd.com
Reply-To: chuck@trantor.harris-atd.com
Organization: Advanced Technology Dept, Harris Corp, Melbourne, FL
Lines: 56

In article <971@elan.Elan.COM>, tom@elan.Elan.COM (Thomas Smith) writes:
> [ several good arguments for delaying creation of dialog boxes ]

     I agree with Thomas Smith, and have always delayed dialog creation to
make tools start faster.  Using Guide, I always have the same harness to
being up a dialog box:

static	dialog_objects	*dialog = NULL;

Menu_item	edit_filters(item, op)

Menu_item	item;
Menu_generate	op;

{
	if (op == MENU_NOTIFY) {
	   xv_set(base_frame, FRAME_BUSY, TRUE, NULL);
	   if (dialog == NULL) {
	      dialog = dialog_objects_initialize(NULL, base_frame);
	      place_dialog(base_frame, dialog->sub_frame);
	      /* one time only initialization here */
	      }
	   if (xv_get(dialog->sub_frame, XV_SHOW) == FALSE) {
	      update_dialog_values();
	      }
	   xv_set(dialog->sub_frame, XV_SHOW, TRUE, NULL);
	   xv_set(contool_base->base, FRAME_BUSY, FALSE, NULL);
	   }
	return item;
}

     This works for all cases: the first time the user presses the button or
picks the menu entry, the routine creates the dialog using the Guide-
generated initialize routine and performs one-time-only tweaking of the
window.  It also calls my place_dialog() routine, which puts the dialog
in a logical place with respect to the base frame.  On subsequent calls,
the window is either simply redisplayed (if it is mapped but obscured) or
reinitialized and reopened (if it is not mapped).  The update_dialog_values()
is the same routine bound to the reset button, which every dialog should
have.  I also make the base frame go busy to clue the user that some time
is being taken to make things right.

     I like this approach because I get minimal startup time, nice handling
and placement of dialogs, and consistent behavior: when you press a button
or pick a menu item, that dialog will either be opened or moved to the
front of any obscuring windows.  Makes for a nice, orthogonal interface.

-- 

Chuck Musciano				ARPA  : chuck@trantor.harris-atd.com
Harris Corporation 			Usenet: ...!uunet!x102a!trantor!chuck
PO Box 37, MS 3A/1912			AT&T  : (407) 727-6131
Melbourne, FL 32902			FAX   : (407) 729-3363

A good newspaper is never good enough,
	but a lousy newspaper is a joy forever.		-- Garrison Keillor