dhoyt@vx.acs.umn.edu (David Hoyt) (12/13/90)
In article <1990Dec13.090206.925@actrix.gen.nz>, Bruce.Hoult@bbs.actrix.gen.nz writes... >You forgot *modeless* dialogs... Er, and I think MacApp uses the standard >mechanism for alerts. No, MacApp doesn't do clasical 'modal' dialogs at all (even for alerts), but rather simulates them with windows. If you compile with the qInspector option you can test this by selecting the model/modeless options in the Inspector menu. This allows you to check the 'look and feel' of model vs. modeless dialogs at runtime. david | dhoyt@vx.acs.umn.edu | dhoyt@umnacvx.bitnet
Bruce.Hoult@bbs.actrix.gen.nz (12/15/90)
In article <2896@ux.acs.umn.edu> dhoyt@vx.acs.umn.edu writes: > In article <1990Dec13.090206.925@actrix.gen.nz>, Bruce.Hoult@bbs.actrix.gen.nz writes... > >You forgot *modeless* dialogs... Er, and I think MacApp uses the standard > >mechanism for alerts. > > No, MacApp doesn't do clasical 'modal' dialogs at all (even for alerts), > but rather simulates them with windows. If you compile with the qInspector > option you can test this by selecting the model/modeless options in the > Inspector menu. This allows you to check the 'look and feel' of model vs. > modeless dialogs at runtime. > > david | dhoyt@vx.acs.umn.edu | dhoyt@umnacvx.bitnet There are plenty of calls to StopAlert, CautionAlert etc in the MacApp sources. And your argument is circular: you can't use the Inspector to play with dialogs and alerts unless they are using uDialog instead of the Dialog manager, so saying you can set the modal/modeless option is rather pointless -- you *can't* do it for dialog manager stuff. -- Bruce.Hoult@bbs.actrix.gen.nz Twisted pair: +64 4 772 116 BIX: brucehoult Last Resort: PO Box 4145 Wellington, NZ
jnixon@spam.ua.oz (John Nixon) (12/17/90)
In article <1990Dec14.165910.27928@actrix.gen.nz> Bruce.Hoult@bbs.actrix.gen.nz writes: [quotes deleted] >There are plenty of calls to StopAlert, CautionAlert etc in the MacApp >sources. [more stuff deleted] I realize this is a little off the subject now, but here goes ... I have just started programming the Mac (IIcx, Think Pascal 3.0), and like the idea of using StopAlerts et al. The problem is, I would also like to be able to centre (or center --- when in Rome ...) these ``built-in'' alerts/dialogs. Could some kind soul let me know if this is possible? Should I just create my own resource and do it the ``long-hand'' way? I don't have MacApp, but I expect if it uses calls to StopAlert, CautionAlert, etc. and these are able to be placed in the correct position on the screen (as per the Human Interface guidelines), it would have been done properly and in the neatest way possible. Email replies if you like, or post too, I don't mind which! John Nixon Disclaimer: What disclaimer? Quote: Which quote? Address: Whose address?
wdh@well.sf.ca.us (Bill Hofmann) (12/19/90)
In article <458@spam.ua.oz> jnixon@spam.ua.oz (John Nixon) writes: >The problem is, I would also like to >be able to centre (or center --- when in Rome ...) these ``built-in'' >alerts/dialogs. Could some kind soul let me know if this is possible? Yes. The process is: 1. Call GetResource('ALRT', <id>) and save into an AlertTHndl variable 2. The first field in an AlertTemplate is the boundsRect of the alert window. 3. Manipulate the boundsRect in memory to center it (screenBits.bounds, or on a ColorQD machine, find the GDevice you want to center it on) This boundsRect is in global coordinates. 4. Call Alert() or NoteAlert(), etc. 5. Since Alert... calls GetResource('ALRT',<id>), it'll get your manipulated data. 6. That's all there is. Don't mark the resource changed. -Bill Hofmann
bin@primate.wisc.edu (Brain in Neutral) (12/19/90)
From article <22233@well.sf.ca.us>, by wdh@well.sf.ca.us (Bill Hofmann): | In article <458@spam.ua.oz> jnixon@spam.ua.oz (John Nixon) writes: |>The problem is, I would also like to |>be able to centre (or center --- when in Rome ...) these ``built-in'' |>alerts/dialogs. Could some kind soul let me know if this is possible? | | Yes. The process is: | | 1. Call GetResource('ALRT', <id>) and save into an AlertTHndl variable | 2. The first field in an AlertTemplate is the boundsRect of the | alert window. | 3. Manipulate the boundsRect in memory to center it (screenBits.bounds, | or on a ColorQD machine, find the GDevice you want to center it on) | This boundsRect is in global coordinates. This same technique can also be used to make the alert come up right on top of your application's window, which can be more convenient if that window is not near where the aler would otherwise come up. (Test that FrontWindow() != nil, first, though and use screenBits as above if it is.) | 4. Call Alert() or NoteAlert(), etc. | 5. Since Alert... calls GetResource('ALRT',<id>), it'll get your | manipulated data. | 6. That's all there is. Don't mark the resource changed. You might also call ReleaseResource() since you don't need it anymore. -- Paul DuBois dubois@primate.wisc.edu
jln@casbah.acns.nwu.edu (John Norstad) (12/19/90)
Apple's Human Interface Note #6 gives guidelines for the centering of dialogs and alerts. Dialogs and alerts should sometimes be centered on the "main" screen (the one containing the menu bar), and sometimes on the screen which has the maximum intersection with the frontmost window. I have a reusable MPW C routine which does this centering according to the guidelines. It's part of my Disinfectant sample source code (module utl, routine utl_CenterDlogRect). Write to me if you'd like a copy. Sorry - this has nothing to do with either MacApp or srolling lists in dialogs :-) John Norstad Academic Computing and Network Services Northwestern University jln@casbah.acns.nwu.edu
oster@well.sf.ca.us (David Phillip Oster) (12/19/90)
In article <458@spam.ua.oz> jnixon@spam.ua.oz (John Nixon) writes: >I have just started programming the Mac (IIcx, Think Pascal 3.0), and like >the idea of using StopAlerts et al. I've given up on all the ...Alert() calls in all my commercial code. Consider: 1.) they are hard to center (remember to center o ver the current document, which might be on another CRT, not just center on the main screen.) 2.) They are hard to parameterize. You just about have to use ParamString(), and if you have a pattern like "Save ^0 befoere closing?" and the user happens to name his file "^0". ParamString() will inifinite loop, crashing the machine. Also, if you make the Edittext box big enough for the largest possible filename, then it looks funky: too much white space on normal files. Modern programs disable the menu bar during editText-less modal dialgos, anfd pass update events/deactivate events to windows behind the alert. All possible from a filter function, but tedious. Instead, I wrote a package thaty looks like an alert, but has the behavior I want, including auto-sizing the dialog to like nice for the amount of text in it. -- -- David Phillip Oster - At least the government doesn't make death worse. -- oster@well.sf.ca.us = {backbone}!well!oster