Protected stacks in 2.61 (was For goodness sake!)
FlexibleLearning at aol.com
FlexibleLearning at aol.com
Fri Sep 17 10:53:41 EDT 2004
It is all rather worrying, Robert, and I can confirm that simply closing a
stack no longer re-sets the protection.
Bug 546 (http://support.runrev.com/bugdatabase/show_bug.cgi?id=546) requests
the ability to re-set protection without closing the stack, but it only has
15 votes. If 'clone' is a different issue, perhaps someone should bugzilla
it. However, since there is an increasing number of 'prohibited actions' in
protected stacks including 'clone', I would humbly suggest that v2.61 could be
considered 'broke' in this respect and in critical need of repair by addressing
546 urgently.
Yip... Hugh still has a serious bee in his bonnet on this one!
/H
-------- Previous msgs --------
From: Robert Brenstein <rjb at robelko.com>
Subject: Re: For goodness sake!
Date: Fri, 17 Sep 2004 02:51:14 +0200
I just tested this under OS9.
Engine 2.5.1 and 2.6
drag-copy a button - works for password-protected stack
clone a button - works for password-protected stack
clone a stack - works for password-protected stack
set the script of btn - error that stack is protected
Engine 2.6.1
drag-copy a button - still works for password-protected stack
clone a button - error msg that stack is password protected
clone a stack - error msg that stack is password protected
set the script of btn - error that stack is protected
So there is definitely change in behavior of the clone command. I do
not see anything related in Bugzilla or mentioned in Whats New.
What I found worrisome is that when I create a new stack, password
protect it, close it (close box or msg box command), then open it
again, it is NOT password protected. If I quit MC to flush memory and
relaunch, the password protection becomes active. Fortunately, this
is likely an issue at development time only.
Robert
----------------------------------------------------
More information about the metacard
mailing list