Path: utzoo!mnetor!uunet!mcvax!uvabick!thomas From: thomas@uvabick.UUCP (Thomas Fruin) Newsgroups: comp.sys.mac.programmer Subject: Re: MultiFinder switch bug with custom WDEFs Message-ID: <244@uvabick.UUCP> Date: 24 Apr 88 03:02:11 GMT References: <242@uvabick.UUCP> <8700@apple.Apple.Com> Organization: uvabick Lines: 39 Keywords: MultiFinder doesn't allow switching when it thinks it sees a dBoxProc Darin Adler writes: > Although this is a bug, I have heard that some here want to retain it as a > feature. You see, if someone wants to create a non-standard WDEF that is a > modal-type window, there is nothing he can do *without* this bug. With it, > he only needs to define his modal-looking window as variation 1 (and avoid > that variation the rest of the time), and MultiFinder will respect the modal > window. > > What do you think? Hmm, hadn't thought of it that way. It's not a bad idea. One could still argue that people who write custom WDEFs that should behave modal will take the trouble to treat them as modal in their source, but I still like the idea. But make sure to document this new "feature" :) Phil Goldman writes: > dBoxProc is reserved for modal dialogs, no matter what the WDEF is. > This is necessary because we have to allow for the system (or even > an app) to easily patch the standard WDEF by adding some code to the front > and then falling thru to the standard one. This would cause problems if we > checked the resource ID too. What a dirty thing to do! I thought I had seen some pretty bad things one could do with WDEFs in MacTutor, but this beats everything ... Seriously, I hadn't thought of this one. Anyway, I had to put some extra code in my own application (that uses the custom WDEF), because I had used up all 4 bits in the variation code. -- Thomas Fruin fruin@hlerul5.BITNET University of Leiden thomas@uvabick.UUCP University of Amsterdam dibs@well.UUCP hol0066.AppleLink 2:508/15.FidoNet The Netherlands