[comp.sys.mac] Graying Out Text Items

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.