mjohnson@Apple.COM (Mark B. Johnson) (02/27/90)
Movable Modal WDEF is now available via anonymous FTP
on Apple.com (IP 130.43.2.2). You can find it in the
~ftp/pub/dts/human.interface/goodies directory.
The Movable Modal WDEF file is the WDEF described in Human
Interface Note #4, Movable Modal Dialog Boxes. This WDEF
includes all previous system window types and adds two new
variants:
5 plain movable modal
13 (5+8) movable modal with zoom box
This window type will be included in System 7.0, but the
Human Interface Group is releasing it in this form now for
use on current systems before 7.0 is released.
This is NOT an official System Software release, so you
should use this WDEF at your own risk, as it may contain
bugs which have not yet been found. If you find any bugs
with this WDEF, please use the Outside Bug Reporter
Application to report them to Developer Technical Support
at MacDTS@AppleLink.Apple.com.
--
Mark B. Johnson AppleLink: mjohnson
Developer Technical Support domain: mjohnson@Apple.com
Apple Computer, Inc. UUCP: {amdahl,decwrl,sun,unisoft}!apple!mjohnson
"You gave your life to become the person you are right now. Was it worth it?"
- Richard Bach, _One_bowman@reed.UUCP (Eric Bowman) (02/28/90)
In article <39013@apple.Apple.COM> mjohnson@Apple.COM (Mark B. Johnson) writes: >Movable Modal WDEF is now available via anonymous FTP >on Apple.com (IP 130.43.2.2). You can find it in the >~ftp/pub/dts/human.interface/goodies Reed doesn't have ftp -- could someone possibly BixHex 4 this stuff and send it to me @: bowman@reed.bitnet <or> bowman@reed.UUCP Thanks a lot! bOBo
jackiw@cs.swarthmore.edu (Nick Jackiw) (03/01/90)
mjohnson@Apple.COM (Mark B. Johnson) writes: > Movable Modal WDEF is now available via anonymous FTP > on Apple.com (IP 130.43.2.2). You can find it in the > ~ftp/pub/dts/human.interface/goodies directory. Awesome! I got it, I use it, I like it. > The Movable Modal WDEF file is the WDEF described in Human > Interface Note #4, Movable Modal Dialog Boxes. This WDEF > includes all previous system window types and adds two new > variants: > > 5 plain movable modal > 13 (5+8) movable modal with zoom box > I've got a question about this; which may or may not be a bug in the WDEF. (If anyone can confirm that what I'm doing is correct, I'll submit a bug report to Apple.) I want to implement a plain movable modal. The WDEF Resource ID is #128, therefore the ProcID should be (according to IM Vol I) 16*128+5=2053. If I specify 2053 in the DLOG template and add the WDEF to my resource file, GetNewDialog()/ShowWindow() generates exactly what I want--a movable dialog without the zoombox. I handle dragging in my ModalDialog filterProc by detecting mouseclicks, checking FindWindow=inDrag+whichWindow=myDialog, and then DragWindow. I let ModalDialog() field the update events generated when I am dragging the dialog from partially-offscreen to totally-onscreen. Unfortunately, the update-response draws a zoombox. If I move the initial zoomboxless window to the point where half an imaginary zoombox would be offscreen, and then drag back, sure enough--I get the half zoombox drawn in. Am I doing something wrong with my resource numbering? I notice that this behavior also happens if I renumber it to WDEF#0, letting it become responsible for drawing all my window types. (I set procID to 5 in this case, of course.) Help, as always, will heap blessings upon your noble head. -Nick -- +-------------------+-jackiw@cs.swarthmore.edu / !rutgers!bpa!swatsun!jackiw-+ | nicholas jackiw | jackiw%campus.swarthmore.edu@swarthmr.bitnet | +-------------------+-VGP/MathDept/Swarthmore College, Swarthmore, PA 19081--+ "Ah...I've got this CHRONIC pain." _True Believer_
zben@umd5.umd.edu (Ben Cranston) (03/02/90)
In article <CPNFXNB@xavier.swarthmore.edu> jackiw@cs.swarthmore.edu (Nick Jackiw) writes: > I want to implement a plain movable modal. The WDEF Resource ID is #128, > therefore the ProcID should be (according to IM Vol I) 16*128+5=2053. > If I specify 2053 in the DLOG template and add the WDEF to my resource > file, GetNewDialog()/ShowWindow() generates exactly what I want--a movable > dialog without the zoombox. > I handle dragging in my ModalDialog filterProc by detecting mouseclicks, > checking FindWindow=inDrag+whichWindow=myDialog, and then DragWindow. > I let ModalDialog() field the update events generated when I am dragging > the dialog from partially-offscreen to totally-onscreen. Unfortunately, > the update-response draws a zoombox. If I move the initial zoomboxless > window to the point where half an imaginary zoombox would be offscreen, and > then drag back, sure enough--I get the half zoombox drawn in. If the new WDEF is installed in an APPLICATION resource file and you are running under MultiFinder there is a chance the system version of the WDEF will be called sometimes and your new WDEF at other times. This is because update calls to the WDEF happen with the foreground application's A5 world. If you are running any of the altWDef/Next/etc inits that patch the window management calls weird things could happen. Other than that, haven't the foggiest... -- Sig DS.L ('ZBen') ; Ben Cranston <zben@Trantor.UMD.EDU> * Network Infrastructures Group, Computer Science Center * University of Maryland at College Park * of Ulm
jackiw@cs.swarthmore.edu (Nick Jackiw) (03/02/90)
zben@umd5.umd.edu (Ben Cranston) writes: > In article <CPNFXNB@xavier.swarthmore.edu> jackiw@cs.swarthmore.edu > (Nick Jackiw) writes: > > > Unfortunately, > > the update-response draws a zoombox. If I move the initial zoomboxless > > window to the point where half an imaginary zoombox would be offscreen, and > > then drag back, sure enough--I get the half zoombox drawn in. > > If the new WDEF is installed in an APPLICATION resource file and you are > running under MultiFinder there is a chance the system version of the WDEF > will be called sometimes and your new WDEF at other times. This is because > update calls to the WDEF happen with the foreground application's A5 world. > > Sig DS.L ('ZBen') ; Ben Cranston <zben@Trantor.UMD.EDU> That's it Ben, thanks! Outside of MultiFinder it works fine; inside it doesn't as per above (regardless of which application is foreground, it seems). Is there any clever way I can force my WDEF into use without installing it in the System? I'm primarily targeted toward system 6, not 7. I would think that this problem wouldn't occur if I used it as WDEF#128, not WDEF#0, since that would (presum'bly) be the sole WDEF#128 operative. Any further thoughts on this? -- -----Nicholas Jackiw [jackiw@cs.swarthmore.edu|jackiw@swarthmr.bitnet]----- "... Then, with an infernal shovel that increases my strength, I dig out of that inexhaustable mine whole chunks of lice, big as mountains. I split them up with an axe and I transport them in the depths of night to city streets."
jackiw@cs.swarthmore.edu (Nick Jackiw) (03/02/90)
I write: > That's it Ben, thanks! Outside of MultiFinder it works fine; inside it > doesn't as per above (regardless of which application is foreground, it seems). Oops... I guess that's not fully it (see Mark Johnson's posting on WDEF 1.01). Thanks to Ben, Mark, Jim, and all those who responded via e-Mail. -Nick -- -----Nicholas Jackiw [jackiw@cs.swarthmore.edu|jackiw@swarthmr.bitnet]----- "... Then, with an infernal shovel that increases my strength, I dig out of that inexhaustable mine whole chunks of lice, big as mountains. I split them up with an axe and I transport them in the depths of night to city streets."