[futurebasic] Re: [FB] GetPort deprecated in OS X 10.4

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : May 2007 : Group Archive : Group : All Groups

From: Robert Purves <listrp@...>
Date: Mon, 14 May 2007 11:18:35 +1200
Brian Stevens wrote:

> Robert Purves wrote:
>> Why do you want to get or set the port? The port is a QuickDraw  
>> concept. FB's  'window output wNum'  sets the current port to the  
>> window in question.
> In the standard FB appearance runtime version of my app it changes  
> window output and cycles through the dance of saving the current  
> output window, setting the new output window, making updates to  
> controls on the window and restoring the prior output window. If I  
> understand this correctly, there is no need to find a direct  
> replacement  of FB's window output (or     oldwindow = window  
> (_outputWnd)  )  when using CE and windows based on nibs. Is that  
> accurate?

If you are identifying controls by their FB btnNum, then the output  
window must be set to the window in question, because FB btnNum is  
keyed off the port. You can have have a button numbered #1 on several  
different windows, and so the FB runtime converts the combination  
{btnNum, port} into a unique ControlRef.

With .nib windows you typically call GetControlByID to get the  
ControlRef yourself, and the port is irrelevant.

>> To avoid deprecated technology, you don't use ports at all.  
>> Instead you draw, in response to _kEventControlDraw (and at no  
>> other time), into a CGContext belonging to an HIView.
> Thanks Robert.  Now that you mention it, I'm not sure if my current  
> interaction with a window constitutes "drawing".   The window  
> controls were created in IB as either static or non-static edit  
> fields. My thought is to use SetControlData to make changes to them  
> based on user interaction (i.e. user clicks a button and static  
> field content changes). Is this a "drawing" situation?

Yes and no. SetControlData on a text control changes the stored text  
data, then calls HIViewSetNeedsDisplay to indicate that the control  
needs redrawing. When the Carbon event loop mechanisms gets around to  
noticing the redraw request, it sends an event {kEventClassControl,  
kEventControlDraw} to the control. Typically the redraw is handled  
automatically by the control's default draw handler, although you can  
install your own handler for this event and do anything you like.

Robert P.