Hello Richard,
Thank you for your comments!
You wrote:
If you're copying objects, you may find it both more secure and more
convenient to maintain to have as few handlers as possible in those
objects, which merely call handlers in a central library or your app's
mainstack to do the real work,
I did this as you suggests, but since 2 weeks I do it in a more extremistic
way: I (almost) do NOT HAVE ANY script in such objects I want to copy from
stack to tempstack and back. I use the event hierarchy for solving this. In the
stackscript (or cardscript if appropriate), which gets any event from such
objects with empty scripts, I have sth like:
on mouseDown
if the short name of the owner of the target = content then
-- there is only one group content
grab me
select the target
-- etc.
else
...
end if
This has the result that you can move around only the selected object within
the group content, copy the group content from the stack to the tempstack
and back - without disturbing the other objects in the card. And it allows
easily changing the handlers in later versions using the same group content
edited by previous versions.
Since
a) I embed the important (password protected and some not protected) stacks
into the standalone
and
b) as Chipp pointed out the standalone binary cannot be decompiled as easy as
in 2.2.1
and
c) I can load my own encrypted stacks by decrypt stackbinary; go stack
stackbinary
and
d) I even can use the passkey syntax for opening extern protected stacks from a
.rev file by a routine in the standalone which knows the passkey for these
external stacks
I can live with the password mechanisms of runrev.
Regards, Franz
To: [EMAIL PROTECTED]
use-revolution@lists.runrev.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
