Path: utzoo!attcan!uunet!aplcen!samsung!brutus.cs.uiuc.edu!psuvax1!xavier!jackiw From: jackiw@cs.swarthmore.edu (Nick Jackiw) Newsgroups: comp.sys.mac.programmer Subject: Re: Movable Modal WDEF Message-ID: Date: 2 Mar 90 14:58:35 GMT References: <39013@apple.Apple.COM> <6192@umd5.umd.edu> Sender: news@xavier.swarthmore.edu (USENET News System) Reply-To: jackiw@cs.swarthmore.edu (Nick Jackiw) Organization: Visual Geometry Project, Swarthmore College, PA Lines: 32 zben@umd5.umd.edu (Ben Cranston) writes: > In article 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 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."