rs4u+@ANDREW.CMU.EDU.UUCP (06/12/87)
I don't think it's necessary to define a UserItem to gray out an item. The following bit shuld work: PROCEDURE GrayDItem(d:DialogPtr; item:Integer); VAR itemType : Integer; itemHand : Handle; itemRect : Rect; pState : PenState; BEGIN GetPenState(pState); {save the pen's state} GetDItem(d, item, itemType, itemHandle, itemRect); {Get the dialog item} PenPat(gray); PenMode(PatBic); {set gray pen, PatBic drawing mode} PaintRect(itemRect); {gray out the item} SetPenState(pState); {restore the pen's state} END; This way, you don't need any UserItems, nor do you have to worry about placing the items in correct order. --Rich ig
lsr@apple.CSNET (Larry Rosenstein) (06/12/87)
Your code for GrayDItem is perfect. But the question is when do you call GrayDItem? One way is to define a UserItem. Another way is to provide a filter proc to ModalDialog that checks for update events and when it gets one, calls DialogSelect to do the update and then GrayDItem to gray out the item. The filter proc would return TRUE to indicate that it handled the event. I think it is OK to call DialogSelect for a modal dialog (that is what ModalDialog does after all). If you just gray out the item when the dialog first appears, then it will lose its grayness if an update event happens. An update event could occur, for example, if a screen saver blanks the screen while the dialog is up. (A lot of program seems to make the mistake of drawing in the dialog window and expecting it to always show up.) Larry
han@apple.UUCP (06/14/87)
In article <cUnz9Qy00UhTNoY1YA@andrew.cmu.edu>, rs4u+@ANDREW.CMU.EDU (Richard Siegel) writes: > > I don't think it's necessary to define a UserItem to > gray out an item. The following bit shuld work: > > PROCEDURE GrayDItem(d:DialogPtr; item:Integer); > BEGIN > END; > > This way, you don't need any UserItems, nor do you > have to worry about placing the items in correct order. > > --Rich However, if another dialog comes out in front, or something, and goes away requiring an update event for the dialog, the graying will not occur unless you explicitly do update events in your ModalDialog FilterProc. The recommended way is to use a useritem. Period. This message has been brought to you from the Apple Thought Police. War is Peace. Love is Hate. Bugs are Features. :-) ===================================================================== Byron Han | UUCP: {sun,voder,nsc,mtxinu,dual}!apple!han Apple Computer, Inc. | CSNET: han@apple.csnet 20525 Mariani Ave, | ATTNet: 408-973-6450 Cupertino, CA 95014 | GENIE: BYRONHAN APPLELINK: HAN1 MS 27Y | CSERVE: 72167,1664 ===================================================================== All opinions and statements do not necessarily represent those of my employer, Apple Computer Inc. =====================================================================
drc@dbase.UUCP (Dennis Cohen) (06/15/87)
In article <cUnz9Qy00UhTNoY1YA@andrew.cmu.edu>, rs4u+@ANDREW.CMU.EDU (Richard Siegel) writes: > > I don't think it's necessary to define a UserItem to > gray out an item. The following bit shuld work: > <There followed an example procedure which will do (essentially what was wanted)> One slight problem with this approach is the number of places you have to trap the condition and make sure it is done right. Activate events on your window, updates, etc. It is far easier to do it as a useritem and let the dialog mgr. take care of it through its own methods (calling your action-proc when needed). Dennis Cohen Ashton-Tate Glendale Development Center dBASE Mac Development Team -------------------------- Disclaimer: I said it, I thought of it, my employer and I have never discussed it. Leave them alone.