Protecting Plugin stacks
Peter Haworth
pete at lcsql.com
Tue Jul 10 13:17:00 EDT 2012
I'm about to make my first plugin stack available and wondering how folks
who have released plugins in the past have dealt with protecting them in
various ways.
I've password protected the stacks so the scripts can't be modified but as
I've posted recently, that doesn't prevent the Inspector palette being
opened and values changed for any object in the plugin. I've written
setProp/getProp handlers to create virtual properties stored in script
variables so at least custom properties can't be changed.
All that's left is the built in Livecode properties. Here's what I've
tried so far.
Set the cantModify/cantDelete properties of each stack in the plugin to
true. No good, still allows the user to open an inspector palette for any
object from the Application Browser and even change those settings back to
false.
According to the User Guide, plugins are opened as palettes by default.
That would help but it's not happening in my case - the plugin is opened
as a toplevel stack, even though its plugin settings say it should open as
a palette. This with LC 5.5. Is there some special step I should be
taking to identify the stack as a plugin other than saving it in the
Plugins folder?
Setting the style of the plugin stacks to palette or modeless helps because
it forces the use of the Browse tool when the stack is opened but the
Inspector palette is still available from the Application Browser.
Seems like the best I can do is have the plugin stacks be modeless, but
even that seems to be a problem since the main stack insists on opening as
toplevel.
Maybe I'm just being overly paranoid about this but I thought it would be
worth asking how others have dealt with this situation in the past.
Pete
lcSQL Software <http://www.lcsql.com>
More information about the use-livecode
mailing list