Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Using modeless dialogs in DAs
Message-ID: <10313@hoptoad.uucp>
Date: 19 Feb 90 08:30:53 GMT
References: <1059ghassemi@yvax.byu.edu> <9958@hoptoad.uucp> <1525@krafla.rhi.hi.is>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 51

In article <1525@krafla.rhi.hi.is> sigurasg@rhi.hi.is (Sigurdur Asgeirsson)
writes:
>I'm trying to write a DA in LSC 4.0 and wanted to use a modeless 
>dialog as its main window, but I have run into a few problems.
>In a DA you have to set the WindowKind field to your refNum so
>that the device manager can pass the events concerning the
>window to the DA (and handle dragging, closing etc.).
>However IsDialogEvent seems to want the WindowKind field set
>to dialogKind, and refuses to recognize any events at all.
>No sweat me thought, I'll just pass the events right on to 
>DialogSelect without asking IsDialogEvent first

No, the thing to do is spelled out in Tech Note #5.  Set the windowKind
to dialogKind (2) before calling IsDialogEvent etc.  Set it back to
your reference number on exit from the desk accessory code.

>this seems
>to work as long as I run the damn thing as an application
>with the stuff in DA-stuff folder that comes with LSC, but
>as soon as I try to run it as a DA everything goes haywire.

You and everybody else.  This thing really does not work close enough
to how a desk accessory works to be valuable for early debugging.  If
you already have a desk accessory working correctly, then this might be
a valuable way to maintain it and add new features, but it's not good
for creating new DAs.

>If I run it from LSC the DA shell 'unexpectedly quits'
>with errors 1,2 or 3. DA handler on the other hand just
>quietly leaves along with all DA's that are open at the
>time. I do have a couple of userItems in the dialog, and
>the error seems to be in the drawProc for one of those, but
>why does it work as an application, and not as a DA?

Probably because when your user item procedure is called from an
application, it uses globals register A5, which is guaranteed to be
preserved, but when it's called as a DA, it's using register A4, which
is almost guaranteed *not* to be set up correctly.  You need to do a
SetUpA4()/RestoreA4() in your user routine if it accesses any globals.
Even more painful, this has to be in the same source file as the
RememberA0/SetUpA4 that stashed it in the first place.  I generally
store any data I need in the dialog refCon so I don't have to access
global variables from my user item procedures.
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com

"He goes on about the wailing and gnashing of teeth.  It comes in one
 verse after another, and it is quite manifest to the reader that there
 is a certain pleasure in contemplating the wailing and gnashing of
 teeth, or else it would not occur so often."
	-- Bertrand Russell, "Why I Am Not a Christian"