NewObject ids (was: PlugIn Immunity)

FlexibleLearning at aol.com FlexibleLearning at aol.com
Wed Oct 18 13:59:08 CDT 2006


>> The 'clone' command places the id of the newly created object in  'it'... I
>> am looking for a way of identifying this information for a  cloned object
>> inside a 'newField[btn,sb,player etc]' handler.  The only solution I can 
>> think of is to use a global, set in the clone command  itself.

> How about getting the long id of the "last field" - that  should be the 
field
> object that was just created...

Not always,  Ken. The new object could be created in a group (eg using the 
clone cmd) so it  would not be the 'last' one, but you are spot on with 'the 
target' and testing  that against the 'last' object.
 
I don't think there is a generic solution for plugin immunity until Rev  
adjusts the revFilterStacksLists handler. However, the following does test [1]  
that the last created object is the same as the 'last' object and that [2]  the 
stack allows controls to be added interactively. It fails, of course,  if the 
stack can create its own last control, but then there is no generic way  that 
I can think of to test the difference between a self-initiated and a  
ToolsPalette-initiated operation. For my purposes, however, the following  deals with 
'unwanted controls' whilst allowing the stack to create its own  controls as 
required...

# PLUGIN IMMUNITY
on newButton
checkRevImmunity the long  id of the target
pass newButton
end newButton

on checkRevImmunity tLID
if (the mode of this stack >1) AND  (the long id of last control=tLID) then
delete last  control    
beep; exit to top
end  if
end checkRevImmunity
 
This has been an interesting (if unexpectedly forced) excursion and my  
thanks to all who assisted in arriving at this solution, both on and off list.  
Like many things, it is all so obvious with the 20:20 vision of hindsight.

/H
FLCo


More information about the metacard mailing list