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.
On 10/18/06 1:13 AM, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
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
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
revFilterStacksList
this is what I will be implementing in the Scripter's Scrapbook
frontScript...
# PLUGIN IMMUNITY
on newButton
ssBkCheckRevImmunity
pass newButton
end newButton
on newField
ssBkCheckRevImmunity
pass newField
end newField
on newGraphic
ssBkCheckRevImmunity
pass newGraphic
end
And a property-based workaround...
on newField [newButton / newScrollbar / newPlayer etc]
ssBkCheckRevImmunity
pass newField
end newField
on ssBkCheckRevImmunity
if the revblessed of stack the mainstack of this stack=true AND \
the mode of this stack 1 then
delete last control
beep
exit
Both my 'brilliant' ideas fail to take account of internally created objects.
Back to drawing board.
/H
___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard
Hi hugh,
you might want to try this (and variations for the other controls) In
the stack script:
on newButton
if revTools is in the executionContexts then
delete the target
send clearSelection to me in 50 milliseconds
end if
pass newButton
end newButton
on clearSelection
At 1:53 PM -0400 10/14/2006, [EMAIL PROTECTED] wrote:
Is there a way to stop Rev being able to create new controls in a stack that
is designed to work as a Rev plugin?
This isn't as elegant as preventing creation of the control, but you
can trap newButton and the other new[Control] messages
Is there a way to stop Rev being able to create new controls in a stack
that
is designed to work as a Rev plugin?
This isn't as elegant as preventing creation of the control, but you
can trap newButton and the other new[Control] messages and delete
(possibly with an error message to the
How about just making the stack a palette...then Rev can't add
controls to it because they always get added to the topStack (assuming
a topStack is open).
-Chipp
___
metacard mailing list
metacard@lists.runrev.com
At 8:56 PM -0500 10/16/2006, Chipp Walters wrote:
How about just making the stack a palette...then Rev can't add
controls to it because they always get added to the topStack (assuming
a topStack is open).
That's true when you use the New Control submenu, but you can drag
them from the tool
Is there a way to stop Rev being able to create new
controls in a stack that is designed to work as a Rev
plugin? maybe setting the "cantmodify" to true does work for
you?Not an option I'm afraid, Klaus. The plugin stack is designed to be
content-modifiable. The stoic insistence by Rev's
On 10/15/06 12:38 PM, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
Is there a way to stop Rev being able to create new controls in a
stack that is designed to work as a Rev plugin?
maybe setting the cantmodify to true does work for you?
Not an option I'm afraid, Klaus. The plugin
Is there a way to stop Rev being able to create new controls in a stack that
is designed to work as a Rev plugin?
/H
___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard
Hi Hugh,
Is there a way to stop Rev being able to create new controls in a
stack that
is designed to work as a Rev plugin?
maybe setting the cantmodify to true does work for you?
/H
Best
Klaus Major
[EMAIL PROTECTED]
http://www.major-k.de
How can we stop a stack used as a Rev plugin from accepting dd controls
from Rev's tools palette? Even stacks that are modeless and palette are not
immune.
Or have I missed something?
/H
___
metacard mailing list
metacard@lists.runrev.com
16 matches
Mail list logo
