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