On Mar 1, 2008, at 11:15 AM, David Bailey wrote:

> Thanks to those that responded.  I must admit to difficulty in  
> knowing then a toolbox shows an @ character and you need to use the  
> # because.....
>
>
>
> "If a a function or procedure expects to receive a variable (to  
> which it may point for an address) as a parameter, you cannot  
> substitute a specific address.  The pound (#) symbol overrides that  
> feature and tells FB not to convert the parameter to an address."

Yes,  probably a little obtuse. Maybe I can clarify by using the  
posted code:



dim as IconSuiteRef @ theIconSuite
dim as OSStatus err

err = _paramErr
theMenu = fn GetControlPopupMenuHandle( popupButton )
long if ( theMenu )
err = fn GetIconSuite( @theIconSuite, _myIconResID,  
_kSelectorAllAvailableData )
long if ( err == _noErr )
err = fn SetMenuItemIconHandle( theMenu, 2, _kMenuIconSuiteType,  
#theIconSuite )

[1] An IconSuiteRef is a type for  a handle variable ( see Tlbx  
Icons.incl for the #define ). Therefore, the variable, theIconSuite  
is essentially a handle variable. That variable has an address in  
memory where it resides.

[2] The call to fn GetIconSuite  populates the theIconSuite variable  
with a handle. After the call,  theIconSuite is not just a handle  
variable, it also *contains* a handle. It is the contents we need  
(which also happens to be another address ---but it is the handle )  
and not the address of the variable itself.

[3] The last parameter of fn SetMenuItemIconHandle requires a handle  
to the icon.  Well, we have a handle to the icon in theIconSuite, so  
it would seem that passing : err = fn SetMenuItemIconHandle( theMenu,  
2, _kMenuIconSuiteType, theIconSuite )  would work, right? In some  
languages yes ( like C ), but not in FB. FB does things for us in  
many cases to try to help. In this case FB will pass the address of  
the handle variable ( which we know is NOT what we want ) instead of  
just the handle. The '#' symbol prefix tells FB to leave it alone and  
just pass as is.

[4] The situation described is often seen in code where pointers are  
passed to local functions and those same pointers are subsequently  
used in calls within the local function:

local fn someFunc ( aFileRef  as ^FSRef )  // pointer to an FSRef is  
passed to the function
dim as OSStatus err

err = fn SomeToolBoxCallThatRequiresAnFSRef ( #aFileRef ) // just  
pass as is since it is already pointer to an FSRef.

end fn

HTH---

Brian S.