sigurasg@rhi.hi.is (Sigurdur Asgeirsson) (02/17/90)
Help!! 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, 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. 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? Any help on this would be more than welcome. P.S. Is it OK for a DA to call SetDAFont? sigurasg@rhi.hi.is
tim@hoptoad.uucp (Tim Maroney) (02/19/90)
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"