[comp.sys.mac.programmer] Modeless Dialogs

oster@dewey.soe.berkeley.edu (David Phillip Oster) (05/08/88)

>OK, I agree that GetNewDialog and NewDialog can be used for modeless dialogs,
>but the important thing is that the DLOG resource has no way of specifying
>a window type other than modal-dialog. 

Absolutely untrue! just set the procType field to whatever you want. If
you read my prosting on getting background operation of MacTerminal under
multifinder, it gives an example.

juana@dciem.dciem.dnd.ca (Juana Chang) (03/27/90)

Hi!

I was wondering if there exists any more information about modeless dialogs
besides the chapter on the dialog manager in IM-1??  Preferably an
example!!

The dialog I'm trying to achieve will consist of a user item and lots of
buttons.  It's basically a control panel for an air traffic control
simulation, the user item will be filled with an aircraft schedule and the
buttons will be controls for altitude and heading of an aircraft.

Thanks for any information !!  :-)


-- 
_________________________________________________________________________
                          Eat any good books lately?
juana@dciem.dciem.dnd.ca
_________________________________________________________________________

andyp@gvgpvd.GVG.TEK.COM (Andy Peterman) (03/29/90)

In article <3005@dciem.dciem.dnd.ca> juana@dciem.dciem.dnd.ca (Juana Chang) writes:
>I was wondering if there exists any more information about modeless dialogs
>besides the chapter on the dialog manager in IM-1??  Preferably an
>example!!
>
>The dialog I'm trying to achieve will consist of a user item and lots of
>buttons.  It's basically a control panel for an air traffic control
>simulation, the user item will be filled with an aircraft schedule and the
>buttons will be controls for altitude and heading of an aircraft.

It sounds like you should not bother using a dialog and just use a
normal window.  There's a Tech Note (#203 - Don't Abuse the Managers)
that says just that and I'm slowly starting to believe them.  By the
time you've written a filter for a modeless dialog (if you don't think
you need one, just wait) and dealt with the hassles of the user items,
you'll find that simply putting controls in a normal window isn't much
more difficult and gives you much more flexibility.  (Check out the
Control Manager - it does much of what the Dialog Manager does anyway).
In a modeless dialog, you have to deal with events too.

	Andy Peterman

jmidili@hub.cs.jmu.edu (jeff midili) (11/10/90)

Are modeless dialogs actually dialogs or are they windows?  How
do you call one?  Do you create it as a dialog or a window
under resedit?  

It seems that if I declare it as a window with resedit, and create
a windowptr for it within my program, I can display the window, but
not the contents.

If I make it a dialog with resedit, and assign a dialogptr to it
with GetNewDialog, I can show it with SelectWindow() and ShowWindow(),
but I can do anything within the event loop with it.  Like close it
if the goaway box is clicked.  

What is the proper method for handling modeless dialogs????

thanks,

Jeff Midili

jmidili@hub.cs.jmu.edu

russotto@eng.umd.edu (Matthew T. Russotto) (11/11/90)

In article <1990Nov9.184626.3290@hub.cs.jmu.edu> jmidili@hub.cs.jmu.edu (jeff midili) writes:
>
>What is the proper method for handling modeless dialogs????

Don't bother-- the extra complication of IsDialogEvent and DialogSelect
aren't worth it.  Make them windows.  Handle the controls and items yourself,
using the Control Manager, DrawString, and TextEdit yourself.  (at first,
I found it hard to believe that this was easier, but I have found that
it really is).

--
Matthew T. Russotto	russotto@eng.umd.edu	russotto@wam.umd.edu
Tax the rich, and feed the poor -- until there are, rich no more.

stevec@Apple.COM (Steve Christensen) (11/13/90)

jmidili@hub.cs.jmu.edu (jeff midili) writes:
>Are modeless dialogs actually dialogs or are they windows?  How
>do you call one?  Do you create it as a dialog or a window
>under resedit?  
>
>It seems that if I declare it as a window with resedit, and create
>a windowptr for it within my program, I can display the window, but
>not the contents.
>
>If I make it a dialog with resedit, and assign a dialogptr to it
>with GetNewDialog, I can show it with SelectWindow() and ShowWindow(),
>but I can do anything within the event loop with it.  Like close it
>if the goaway box is clicked.  
>
>What is the proper method for handling modeless dialogs????

The only difference between a modal and modeless dialog is how an app handles
it.  Typically a modal dialog lets you diddle some settings, but you can't do
anything else outside the dialog until you click OK or Cancel (for example).
A modeless dialog allows you to switch to other windows or dialogs (even modal
ones), just like a regular window.

Dialog windows (they *are* windows after all) are used when you have a mostly
fixed set of elements to display so you don't have to deal with localization
issues so much.  The layout can be changed and the code in your program doesn't
need to know that it did.  The program just says, "well, the user pressed
button 3, so I need to do this".  If you use a window instead, your program
needs to build up the elements itself since there's no DITL to specify what's
in the window.

So how do you work with a modeless dialog (modal dialogs are easy, just use
ModalDialog())?  Here's a snippet that will do a lot of the work:

	do {
	  if (GetNextEvent(EveryEvent, &theEvent)) {

	    if (theEvent.what == MouseDown) {
	      switch (FindWindow(theEvent.where, &theWindow)) {
		case inSysWindow:
			SystemClick(&theEvent, theWindow);
			break;

		case inDrag:
			DragWindow(theWindow, theEvent.where, &dragRect);
			break;

		case inGoAway:
			if (TrackGoAway(theWindow, theEvent.where)) {
			  // HideWindow(), DisposWindow(), DisposDialog(), ...
			  // ...depends on what you want to do
			}
			break;
	    }

	    if (IsDialogEvent(&theEvent)) {
	      if (DialogSelect(&theEvent, &theDialog, &itemHit)) {
		switch (itemHit) {
		  case xxx:
		  ...
		}
	      }
	    }
	  }
	} while (true);



steve

francis@arthur.uchicago.edu (Francis Stracke) (11/13/90)

In article <46507@apple.Apple.COM> stevec@Apple.COM (Steve Christensen) writes:
>jmidili@hub.cs.jmu.edu (jeff midili) writes:
>The only difference between a modal and modeless dialog is how an app handles
>it.  Typically a modal dialog lets you diddle some settings, but you can't do

Also MF: anything that looks like a modal (that variation of the
standard WDEF) means "don't switch me," even if the app is using
it for something else.  The Thought Police don't want you putting
up modals that aren't!
| Francis Stracke		| My opinions are my own.  I don't steal them.|
| Department of Mathematics	|=============================================|
| University of Chicago		| Non sequiturs make me eat lampshades	      |
| francis@zaphod.uchicago.edu	|   				       	      |

calvin@portia.stanford.edu (Peter Chang) (04/05/91)

Hello Netters,

	I am writing a program that needs some modeless dialogs, and
I have  few questions on how to implement them. I'm learning
how to use the Think Class Library at the same time, so some of
my ideas may seem odd.

	1.	It seems to me that a modeless dialog is just a window with
some buttons, text boxes, and other things. Because it seems
this way to me, would it be advisable to implement it by making
a window with the requisite components built in?

	2. If part 1 was answered with an affirmative, would the best
way to implement this be to override the Pane class with some 
Buttons and other objects thrown on when I need them?

	If there is a better way, a ModelessDialog procedure or 
something, that I am just missing could someone point me in
the right direction, IM 1-3 doesn't seem to have an mention of
it.

	Thanks in advance.

-----------------------------------------------------------------------------
Peter Chang                           | "Better to Trade Knowledge than"
E-Mail: calvin@portia.stanford.edu    |  Something of Value"
Snail Mail: PO Box 9603               |
            Stanford, CA  94309       | "Eagles may soar, free and proud,
                                      |  but Weasels never get sucked into
                                      |  Jet Engines"

time@ice.com (Tim Endres) (04/05/91)

In article <1991Apr5.081306.511@leland.Stanford.EDU>, calvin@portia.stanford.edu (Peter Chang) writes:
> Hello Netters,
> 
> 	I am writing a program that needs some modeless dialogs, and
> I have  few questions on how to implement them. I'm learning
> how to use the Think Class Library at the same time, so some of
> my ideas may seem odd.
> 
> 	1.	It seems to me that a modeless dialog is just a window with
> some buttons, text boxes, and other things. Because it seems
> this way to me, would it be advisable to implement it by making
> a window with the requisite components built in?

Apple has recommended from the beginning that dialogs only be used
where creating a window would entail much more work. And they have
also recommended you limit dialogs to a small number of items. 
If you implement this as a window, you will enjoy some freedom and
benefits you would not as a dialog, but you will have to do a little
more work.

> 	2. If part 1 was answered with an affirmative, would the best
> way to implement this be to override the Pane class with some 
> Buttons and other objects thrown on when I need them?

I am not sure how MacAPP implements its control objects within Panes
of windows, but it sounds right.

-------------------------------------------------------------
Tim Endres                |  time@ice.com
ICE Engineering           |  uupsi!ice.com!time
8840 Main Street          |  Voice            FAX
Whitmore Lake MI. 48189   |  (313) 449 8288   (313) 449 9208

dmmg1176@uxa.cso.uiuc.edu (David M Marcovitz) (04/06/91)

calvin@portia.stanford.edu (Peter Chang) writes:

>Hello Netters,

>	I am writing a program that needs some modeless dialogs, and
>I have  few questions on how to implement them. I'm learning
>how to use the Think Class Library at the same time, so some of
>my ideas may seem odd.

There is a modeless dialog library for TCL.  It is available for ftp
from standard places (sumex, ...).

--
David M. Marcovitz                     |  internet: marcovitz@uiuc.edu
Computer-based Education Research Lab  |            dmmg1176@uxa.cso.uiuc.edu
University of Illinois                 |  novanet:  marco / cca / cerl

Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) (04/08/91)

Tim Endres writes in a message to All

>       2. If part 1 was answered with an affirmative, would the best
> way to implement this be to override the Pane class with some 
> Buttons and other objects thrown on when I need them?
TE>  I am not sure how MacAPP implements its control objects within 
TE> Panes of windows, but it sounds right

With the TCL's you generally use an instance of CDocument to add various panes
to a window... unless you have a pane that with lots of specific functions built-in,
then you could create a new pane with buttons and other controls. Not even panoramas
are done that way, although you could I suppose. Hmmm...


Lawson
 

--  
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!300!15.88!Lawson.English
Internet: Lawson.English@p88.f15.n300.z1.fidonet.org