Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!aplcen!haven!umd5!zben From: zben@umd5.umd.edu (Ben Cranston) Newsgroups: comp.sys.mac.programmer Subject: Re: Movable Modal WDEF Summary: R U sure MultiFinder isn't shuffling WDEFs on you? Message-ID: <6192@umd5.umd.edu> Date: 1 Mar 90 22:34:22 GMT References: <39013@apple.Apple.COM> Reply-To: zben@umd5.umd.edu (Ben Cranston) Organization: University of Maryland, College Park Lines: 32 In article 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 * Network Infrastructures Group, Computer Science Center * University of Maryland at College Park * of Ulm