Re: [Fxruby-users] Icons and tooltips

[Lyle J. <ly...@kn...>]

On May 23, 2004, at 2:50 AM, Hal Fulton wrote:

>> 1.  The syntax of the "FXPNGIcon.new(application, f.read)" statement 
>> would
>> lead me to think the icon is being attached to the application (e.g., 
>> for
>> purpose of displaying the app in an OS' toolbar when it runs,  
>> perhaps)
>> rather than in the application's FXMainWindow instance.  I'd expect 
>> it to
>> have a "main" argument explicitly naming the window to which it 
>> should be
>> attached, as FxButton.new does.

Several kinds of objects in FOX applications are treated as shared 
resources; these include objects like cursors, fonts and icons. So 
while an icon is associated with a particular FXApp instance (as 
suggested by its constructor) it's a mistake to think of it in terms of 
the application "owning" the icon. In fact, you can use the same, 
single FXPNGIcon instance with your main window, labels, buttons, etc. 
(i.e. any widget that can be decorated with an icon). A mistake I see 
in a lot of FOX programs is that programmers will construct multiple 
icon objects all pointing to the same icon data, e.g.

	0.upto(1000) {
		anIcon = FXPNGIcon.new(getApp(), someIconData)
		anIcon.create
		aTreeList.addItemLast(nil, "some text", anIcon)
	}

The confusion may arise because of how the constructors for 
"non-shared" FOX objects (such as windows) are written. There, the 
first argument is almost always the parent window, and there is a 
definite parent-child containment hierarchy going on there: the 
"parent" window does "own" the child window, in a sense, and if you 
delete the parent window the child window goes away too.

>> 2.  FXTooltip.new's failure to name any particular object leads me to 
>> think
>> it should wire a tooltip into every object in the application (or 
>> rather,
>> the app's main window?) that's built to host a tooltip,  and that the
>> tooltip text is to be gotten from each such object's caption text 
>> (using
>> everything following the first tab.)

There is only one tooltip object (or, rather, it's unnecessary to have 
more than one tooltip object). Whenever the tooltip's update handler 
runs, the tooltip checks to see which widget the mouse cursor is 
currently hovering over. And of course there's a timer in the mix, so 
that the tooltip "waits" a little while before it displays itself. You 
are correct that when the tooltip does display itself, it "asks" the 
current widget under the cursor for its tooltip text and displays that.

Hope this helps,

Lyle