UD040164@NDSUVM1.BITNET (a.d. jensen) (09/06/88)
Here is a problem which has me stumped: I wrote an INIT in LSC3 which basically throws up a dialog box and then messes around with it, then discards it. Basically, I call GetNewDialog (with NULL for the storage), use SetIText and SetCTitle to monkey around with the dialog as needed, then call ModalDialog to handle it, then call DisposDialog to get rid of it. All is well, until the DisposDialog, when I get a system bomb 2. The trouble I have with this is that _nothing_ bad happens until I try to do something with the window (ie: DisposDialog, MoveWindow, etc). This seems very weird. I called Think, and the guy I talked to just sort of said that it couldn't be happening, and he had no idea what was wrong. All of my experimentation has been for nought. No matter where I try to do something with the window, it always crashes. BTW, this _does_ work fine on the Mac II. The guy at Think said something about my dialog getting a bad address or something (which won't bomb on a II), but why doesn't it bomb when changing text, or other things which refer to the dialog? My only idea is that the dialog gets a bad window, but I have no idea of what to do to solve this, if it is the case... Thanks for your help. dale
edmoy@violet.berkeley.edu (09/07/88)
In article <1325UD040164@NDSUVM1> UD040164@NDSUVM1.BITNET (a.d. jensen) writes: >Here is a problem which has me stumped: > >I wrote an INIT in LSC3 which basically throws up a dialog box and >then messes around with it, then discards it. Basically, I call >GetNewDialog (with NULL for the storage), use SetIText and SetCTitle >to monkey around with the dialog as needed, then call ModalDialog to >handle it, then call DisposDialog to get rid of it. All is well, until >the DisposDialog, when I get a system bomb 2. > >The trouble I have with this is that _nothing_ bad happens until I try >to do something with the window (ie: DisposDialog, MoveWindow, etc). >This seems very weird. > >All of my experimentation has been for nought. No matter where I try >to do something with the window, it always crashes. BTW, this _does_ >work fine on the Mac II. Somewhere I read that INITs are "not supposed" to do window and dialog stuff. But even Apple does it in AppleShare, when on bootup it may ask for a password. One thing I do notice is that when the INIT in AppleShare runs, the screen (with the Welcome to Macintosh message) blanks out. I wonder if AppleShare is calling InitWindows(). Perhaps on the Mac II, InitWindows() is called in a different order than on other Macs. If it is called before INITs, then all would be fine. Edward Moy Principal Programmer - Macintosh & Unix Workstation Support Services Workstation Software Support Group University of California Berkeley, CA 94720 edmoy@violet.Berkeley.EDU ucbvax!violet!edmoy
spector@vx2.NYU.EDU (David HM Spector) (09/07/88)
As I recall from looking at an LSC version of ShowINIT (a klone of the
MPW object written by Apple's Paul Mercer) which shows the icons of INITs
at System startup time, you need to have your own QD globals set up, because
at INIT31 time the universe is not fully formed yet, and as such QuickDraw
and things that rely upon it are most likely bound to do bad things.
You might also have to init the managers you are using too... but I've
never tried doing that in an INIT...
Note: I am working from memory on what happens when INITs are started...
if I'm wrong please don't bop me on the head. (read: I hope someone
from Apple can tell us if this is totally correct, or if I've missed the
boat)
_DHMS
-------------------------------------------------------------------------------
David HM Spector New York University
Senior Systems Programmer Graduate School of Business
ARPAnet: SPECTOR@GBA.NYU.EDU Academic Computing Center
USEnet:...!{allegra,rocky,harvard}!cmcl2!spector 90 Trinity Place, Rm C-4
HamRadio: N2BCA MCIMail: DSpector New York, New York 10006
AppleLink: D1161 CompuServe: 71260,1410 (212) 285-6080
"What computer puts out work like this?" "Hire us and we'll tell you."kim@wayne.UUCP (Kim Helliwell) (09/07/88)
In article <1325UD040164@NDSUVM1>, UD040164@NDSUVM1.BITNET (a.d. jensen) writes: > Here is a problem which has me stumped: > [ description of crashes when using dialogs ] > > Thanks for your help. > > dale I don't know whether this will help or not, but I have had similar problems (bring up a dialog, then watch it crash when I click in it) and I always have traced it to needing to do an explicit SetPort(dlog) in the dialog handler code. I don't know why you should have to do this--you would think that GetNewDialog() would take care of that for you, but if you are not doing that now, I would try it--it may help. -- "Never let work interfere with your reasons for working." Kim Helliwell
han@Apple.COM (Byron Han, Architect) (09/08/88)
In article <6860023@vx2.NYU.EDU> spector@vx2.NYU.EDU (David HM Spector) writes: > >You might also have to init the managers you are using too... but I've >never tried doing that in an INIT... > >Note: I am working from memory on what happens when INITs are started... >if I'm wrong please don't bop me on the head. (read: I hope someone >from Apple can tell us if this is totally correct, or if I've missed the >boat) > Yes you need to INIT the appropriate managers. For Dialogs, this would be InitGraf(@thePort); InitFonts; InitWindows; TEInit; InitDialogs(NIL); or something like that. ------------------------------------------------------------------------------ Byron Han, Communications Architect "Just say NO to MS-DOS." Apple Computer, Inc. ------------------------------------- 20525 Mariani Ave, MS27Y domain: han@apple.COM Cupertino, CA 95014 UUCP:{sun,voder,nsc,decwrl}!apple!han -------------------------------------- GENIE: BYRONHAN ATTnet: 408-973-6450 Applelink: HAN1 CompuServe: 72167,1664 ------------------------------------------------------------------------------
han@Apple.COM (Byron Han, Architect) (09/08/88)
In article <16736@apple.Apple.COM> han@apple.com.UUCP (Byron Han, Architect) writes: >Yes you need to INIT the appropriate managers. For Dialogs, this would be >InitGraf(@thePort); Oops. thePort is a global variable and as such should not be used. (standalone code and all that). I believe that ShowInit already calls InitGraf for you so if you are using ShowInit you are okay. ------------------------------------------------------------------------------ Byron Han, Communications Architect "Just say NO to MS-DOS." Apple Computer, Inc. ------------------------------------- 20525 Mariani Ave, MS27Y domain: han@apple.COM Cupertino, CA 95014 UUCP:{sun,voder,nsc,decwrl}!apple!han -------------------------------------- GENIE: BYRONHAN ATTnet: 408-973-6450 Applelink: HAN1 CompuServe: 72167,1664 ------------------------------------------------------------------------------
UD040164@NDSUVM1.BITNET (a.d. jensen) (09/08/88)
Well, I got a slug of ideas as to what might be changed, here are the
results:
Call InitGraf - Can't use globals...
Call InitWindows, InitDialogs - Was already doing...
Don't call InitWindows, - El bombo
InitDialogs
Expicitly set the port to - No effect
theDialog
In review, nobody really addressed the quesion of why the DisposDialog
crashes when any other reference to theDialog caused no problems.
Anyway, just to get rid of the dialog, I make another call to InitWindows ().
This is probably pretty stupid, but it gets rid of the dialog without
crashing. Until we have an answer that works, I guess that we're stuck
with this "solution".
Thanks to everyone who responded. It appears that this is a dilemma not
faced often, since dialogs in INITs are uncommon (apart from AppleShare,
QuickMail and BigScreenInit).
dalejayr@well.UUCP (Jay Roth) (09/09/88)
Perhaps your problem is that you're calling DisposDialog to get rid of the dialog. IM says to call CloseDialog "when you're doine with a dialog if you supplied NewDialog or GetNewDialog with a pointer to the dialog storage (in the dStorage parameter) when you created the dialog."
clubmac@runx.ips.oz (Macintosh Users Group) (09/10/88)
In article <6860023@vx2.NYU.EDU> spector@vx2.NYU.EDU (David HM Spector) writes: >As I recall from looking at an LSC version of ShowINIT (a klone of the >MPW object written by Apple's Paul Mercer) which shows the icons of INITs >at System startup time, you need to have your own QD globals set up, because >at INIT31 time the universe is not fully formed yet, and as such QuickDraw >and things that rely upon it are most likely bound to do bad things. Could you post (or mail) a copy of the LSC source code for the ShowInit clone? Thanks in advance, Jason Haines - President, Club Mac Australia's largest Macintosh Users Group, with over 1000 members. Phone Home: +61-2-73-1016 OZ Post: Box 213, Holme Building, Sydney University, NSW, 2006, Australia Internet: clubmac@runx.ips.oz.au UUCP: uunet!runx.ips.oz.au!clubmac
msurlich@immd1.informatik.uni-erlangen.de (Matthias Urlichs - scheme) (09/12/88)
In article <16737@apple.Apple.COM> han@apple.com.UUCP (Byron Han, Architect) writes: > In article <16736@apple.Apple.COM> han@apple.com.UUCP (Byron Han, Architect) writes: > >Yes you need to INIT the appropriate managers. For Dialogs, this would be > >InitGraf(@thePort); > > Oops. thePort is a global variable and as such should not be used. (standalone > code and all that). > > I believe that ShowInit already calls InitGraf for you so if you are using > ShowInit you are okay. > Looking at INIT31 reveals that InitGraf has already been called. However, some Inits do it themselves and leave A5 pointing to anything at all afterwards, so it's bad to call InitGraf (using your own port) and it may create problems not to... Anyone have a good procedure to check if InitGraf has been called? (Like comparing Arrow to a resource which contains a cloned version of the standard cursor?) As an aside, Init31 also checks if the Cached bit is set and skips the INIT/RDEV/cdev file if it is. Anyone have a newer version of AAsk (or a patch) which looks at that bit instead of changing the file type to "xNIT" and similar nonsense :-( ? -- Matthias Urlichs CompuServe: 72437,1357 Delphi: URLICHS Rainwiesenweg 9 Phone: +49+911-574180 8501 Schwaig 2 NetMail: m_urlichs@msn.rmi.de West Germany or: (r)eply and (h)ope
borton@uva.UUCP (Chris Borton) (09/13/88)
A thought occurred to me over the weekend regarding these dialogs being used
when the system is in various states of initialization or unknowns: use
SysError().
This isn't always appropriate, but there are sometimes then you want some
simple info and 1/2 buttons to do something to come up, but you don't know
what the environment is (namely if InitDialogs() has been called). That is
what SysError() is for.
I wish I had thought of that when Mike Scanlin & I were doing nVIR Warn INIT.
Note: I haven't actually done this yet. I just looked up IM and saw the
possibilities. If I'm missing the boat somewhere, please correct me.
-cbb
--
Chris Borton borton%uva@mcvax.{nl,bitnet,uucp}
Rotary Scholar, University of Amsterdam CSerics@eleazar.dartmouth.edu (Eric Schlegel) (09/15/88)
In article <634@faui44.informatik.uni-erlangen.de> m_urlichs@msn.rmi.de (Matthias Urlichs) writes: >... Anyone have a good procedure to check if InitGraf >has been called? (Like comparing Arrow to a resource which contains a cloned >version of the standard cursor?) I believe there's a system global called QDExist (or some such) which indicates whether QuickDraw has been initialized. Check your local copy of MacNosy, IM 3, "How to Write Macintosh Software", or other reference work. ------ Eric Schlegel | DISCLAIMER: I'm just a poor college student, eric.schlegel@dartmouth.edu | which means I'm not responsible for what I | say and I can't pay you if you sue me anyway.
tomj@oakhill.UUCP (Tom Johnson) (09/23/88)
In article <1331UD040164@NDSUVM1> UD040164@NDSUVM1.BITNET (a.d. jensen) writes: >Well, I got a slug of ideas as to what might be changed, here are the >results: >... >In review, nobody really addressed the quesion of why the DisposDialog >crashes when any other reference to theDialog caused no problems. > >dale I haven't been keeping up with this news group for a while, and so this posting may be old news...if it is, you can skip this prior to flaming on... I have recently been having REAL difficulties trying to display a modal dialog in an RDEV I've been working on. I found that if I let the system create the dialog storage on _GetNewDialog, then the dialog gets created o.k. (but doesn't if I reserve the storage for it!!!???). Later, when I call _ModalDialog, (I didn't mention that all of this is from assembly language did I...) the dialog static text gets displayed as usual. When the user quits the dialog, a look at the stackframe (my "A6" world), it is completly trashed. One of the values that is trashed happens to be the DialogHandle returned by the original call to _GetNewDialog. Thus, when I try to call _DisposDialog, passing the (now corrupted) handle, BUS ERROR. The work-around?---I use an alert instead of a dialog!!! This is fascinating to me because Alert calls ModalDialog!! Anyone want to take a stab at this one? I have checked this code VERY VERY VERY carefully. The _GetNewDialog call completes properly and returns the correct handle. Everything is O.K. on the stack prior to the _ModalDialog call, but trashed on return. (p.s. I also had another Mac assembly language weenie check this out. He is also baffled. All we can come up with is that this is an undocumented "feature" of programming RDEV's...I've already found a few more... |Standard Disclaimer |Tom Johnson, Hi-End MPU Marketing |Motorola, Inc. |tomj@oakhill.UUCP