kk@mcnc.org (Krzysztof Kozminski) (08/25/89)
In article <8376@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >Deactivation is indeed a better solution, though it doesn't completely >address the problem of modality. But at least it gives a clear visible >indication of the modal behavior. With text edit items, you can always >disable them by turning them into user items with SetDItem and binding >a "draw light gray" drawing procedure, then doing an InvalRect on the >item's surrounding rectangle. I don't think this causes any problems. OK, I got the following idea: make an additional, inactive userItem that exactly overlaps the text edit item that may be subject to disappearance, and let its procedure draw a gray rectangle in patOr mode. Then just do Show/HideDItem on the text edit item as needed. The userItem shows up only when the text item is hidden, (otherwise it blends with the text box - that's why you need to use 'patOr' mode or to place the userItem underneath the text item) and you don't have to bother storing the control handle, activating/deactivating the item, making sure not to try to get text from your userItem, etc. Tim's proposition also works (I checked - Dialog Manager handles the 'tab loop' correctly), but requires approximately twice as much programming effort (20 lines of code versus 10 :-) On the subject of modality - sometimes you do need things like discussed above - imagine an object with attributes A, B, ..., Z, with attribute B that has a text value and that makes sense only if binary attribute A is set. Using different dialogs for the object, depending on the value of A, would be bothersome both for the user and for the programmer. KK -- Kris Kozminski kk@mcnc.org "The party was a masquerade; the guests were all wearing their faces."
han@Apple.COM (Byron Han) (08/27/89)
In article <1354@speedy.mcnc.org> kk@mcnc.org.UUCP (Krzysztof Kozminski) writes: >In article <8376@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >>Deactivation is indeed a better solution, though it doesn't completely >>address the problem of modality. But at least it gives a clear visible >>indication of the modal behavior. With text edit items, you can always >>disable them by turning them into user items with SetDItem and binding >>a "draw light gray" drawing procedure, then doing an InvalRect on the >>item's surrounding rectangle. I don't think this causes any problems. > >OK, I got the following idea: make an additional, inactive userItem >that exactly overlaps the text edit item that may be subject to >disappearance, and let its procedure draw a gray rectangle in patOr >mode. Then just do Show/HideDItem on the text edit item as needed. Actually, a better solution is to change the editText item into a statText item using GetDItem/SetDItem and to also use an auxilliary userItem which can be hidden if the text edit item is active and shown if the text edit item is deactivated. This aux userItem paints in patOr mode ltGray. +-----------------------------------------------------------------------------+ | Disclaimer: Apple has no connection with my postings. | +-----------------------------------------------------------------------------+ Byron Han, CommToolbox Scapegoat Macintosh - Catch the Wave! Apple Computer, Inc. ----------------------------------------- 20525 Mariani Ave, MS27Y Internet: han@apple.COM Cupertino, CA 95014 UUCP:{sun,voder,nsc,decwrl}!apple!han ------------------------------------ GENIE:BYRONHAN CompuServe:72167,1664 ATTnet: 408-974-6450 Applelink:HAN1 HAN1@applelink.apple.COM -------------------------------------------------------------------------------