Clone command in 2.61
Has 'clone' broken in 2.61 for password protected stacks? Can someone else confirm? /H ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Copy command in 2.61
We seem to have a related issue to the broken 'clone' command in password protected stacks in v2.61... 'Copy [obj] to [dest]' results in a 'Can't cut object [stack is locked]' error. Can anyone else confirm this? Similarly, we used to be able to 'get' and 'put' scripts in password protected stacks (for example "on mouse enter; put line 1 of the script of me into fld "feedback"). This also broke under engine 2.5 I suspect a plot to disable any form of self-modification! /H ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Copy command in 2.61
I spent a good deal of time working with this in 2.5 and ended up simply not password protecting the substacks with scripts which needed to be modified or copied. Ray Horsley Developer, LinkIt! Software On Tuesday, September 14, 2004, at 05:22 AM, [EMAIL PROTECTED] wrote: We seem to have a related issue to the broken 'clone' command in password protected stacks in v2.61... 'Copy [obj] to [dest]' results in a 'Can't cut object [stack is locked]' error. Can anyone else confirm this? Similarly, we used to be able to 'get' and 'put' scripts in password protected stacks (for example on mouse enter; put line 1 of the script of me into fld feedback). This also broke under engine 2.5 I suspect a plot to disable any form of self-modification! /H ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Copy command in 2.61
We seem to have a related issue to the broken 'clone' command in password protected stacks in v2.61... 'Copy [obj] to [dest]' results in a 'Can't cut object [stack is locked]' error. Can anyone else confirm this? Similarly, we used to be able to 'get' and 'put' scripts in password protected stacks (for example on mouse enter; put line 1 of the script of me into fld feedback). This also broke under engine 2.5 I suspect a plot to disable any form of self-modification! /H Hmm, let me get this straight. You were able to change the scripts without setting passkey (unlocking the protection)? That should not be possible and it would be a bug if it was. If this happens after passkey is set, then it sounds like a bug to me (if there is no failure setting passkey). RunRev is indeed keeping the dynamic scripting (self-modification) under wraps so do speak. See Tuviah's comment under bug 546: http://support.runrev.com/bugdatabase/show_bug.cgi?id=546 Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
For goodness sake!
This is now becoming crippling... After v2.5 - We cannot "clone" an object - We cannot "copy" an object - Andwe cannot "set the script" of an object if astack is password protected (I'm using v2.6.1 build 9). All workarounds seemblocked. Okay, top marks for consistency butfor goodness sake...! Aaaargh! /H ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: For goodness sake!
Hi Hugh, This is now becoming crippling... After v2.5 - We cannot clone an object - We cannot copy an object - And we cannot set the script of an object if a stack is password protected (I'm using v2.6.1 build 9). All workarounds seem blocked. Well, this has always been the case with password-protected stacks!!! I might be a bug if it does not work after setting the passkey... Okay, top marks for consistency but for goodness sake...! God is dead! Friedrich Nietzsche :-) Aaaargh! /H Regards Klaus Major [EMAIL PROTECTED] http://www.major-k.de ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: How to do clean install of MetaCard?
But really, this is the first time this has come up. Very few people use the MC IDE, and about 98% of those who do were using it before the acquisition. Not all of us voted :-) Not being a member, it was a hassle-factor to sign up to vote. So add 1 to that very few number. Shari Gypsy King Software -- Mac and Windows shareware games http://www.gypsyware.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: How to do clean install of MetaCard?
On Tuesday, September 14, 2004, at 10:25 AM, Shari wrote: But really, this is the first time this has come up. Very few people use the MC IDE, and about 98% of those who do were using it before the acquisition. Not all of us voted :-) Not being a member, it was a hassle-factor to sign up to vote. So add 1 to that very few number. Add 1 more (discouraged regarding time) for the 'hassle factor' Shari Gypsy King Software -- Mac and Windows shareware games http://www.gypsyware.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard Ray Horsley Developer, LinkIt! Software ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: How to do clean install of MetaCard?
Ray Horsley wrote: On Tuesday, September 14, 2004, at 10:25 AM, Shari wrote: But really, this is the first time this has come up. Very few people use the MC IDE, and about 98% of those who do were using it before the acquisition. Not all of us voted :-) Not being a member, it was a hassle-factor to sign up to vote. So add 1 to that very few number. Add 1 more (discouraged regarding time) for the 'hassle factor' Is it really all that bad? The half-page sign-form didn't seem particularly onerous at the time we polled folks here on it last year. The form is pretty brief compared to other online communities I've seen, and you only need to touch it once. Best of all, after that one-time 45-second inconvenience you have access to many other of Yahoo's thousands interesting groups, including these Transcript-related groups: http://groups.yahoo.com/group/revolution_ipc/ http://groups.yahoo.com/group/RevDocs/ http://groups.yahoo.com/group/revInterop/ http://groups.yahoo.com/group/xTalks/ In addition to: http://groups.yahoo.com/group/MC_IDE/ -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: For goodness sake!
Hi Klaus, Not entirely true. v2.5 prohibited set/get script and copy [obj] in password protected stacks, but clone has always been available. My points: [1] I can appreciate protecting script and copying access to prevent circumventing protected stacks, but clone can do nothing except duplicate in the same environment. [2] If dynamic scripting in protected stacks is being 'phased out', we need to be able to unlock, do whatever, then *re-set* the protection. This last step is not available, and until 2.5 was not required. Not only should it now be available, but it has become a CRITICAL command. /H PS. As for the Nietzsche quote, I feel it both cavalier and wholly inappropriate. This is not the place for such comments. The 'joke' fell flat. original msgs --- Hi Hugh, This is now becoming crippling... After v2.5 - We cannot clone an object - We cannot copy an object - And we cannot set the script of an object if a stack is password protected (I'm using v2.6.1 build 9). All workarounds seem blocked. Well, this has always been the case with password-protected stacks!!! I might be a bug if it does not work after setting the passkey... Okay, top marks for consistency but for goodness sake...! God is dead! Friedrich Nietzsche :-) Klaus Major --- ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
2.61 Hand Cursor
What on earth has happened in this release? 'Set the cursor to hand' now results in a vertical splitter icon! Oh boy... This is not the robust and predictable environment to which I had become accustomed. It would help (or at least show willing) if such changes were flagged in the ReadMe notes. Do we have any other surprises in store, waiting to trip us up? /H "Miffed of Cranleigh" ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: For xxx sake!
Hi Hugh, Hi Klaus, Not entirely true. v2.5 prohibited set/get script and copy [obj] in password protected stacks, but clone has always been available. Ah, sorry, didn't know the latter... My points: [1] I can appreciate protecting script and copying access to prevent circumventing protected stacks, but clone can do nothing except duplicate in the same environment. Yes, so it is kind of useless in protected stack... [2] If dynamic scripting in protected stacks is being 'phased out', Sorry, what do you mean here? we need to be able to unlock, do whatever, then *re-set* the protection. This last step is not available, and until 2.5 was not required. Not only should it now be available, but it has become a CRITICAL command. Sorry, don't get this one either...? You mean setting the passkey, doing whatever, saving and closing the stack DOES remove the password/protection? /H PS. As for the Nietzsche quote, I feel it both cavalier and wholly inappropriate. This is not the place for such comments. The 'joke' fell flat. I guessed... Regards Klaus Major [EMAIL PROTECTED] http://www.major-k.de ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: 2.61 Hand Cursor
What on earth has happened in this release? 'Set the cursor to hand' now results in a vertical splitter icon! Oh boy... This is not the robust and predictable environment to which I had become accustomed. It would help (or at least show willing) if such changes were flagged in the ReadMe notes. Do we have any other surprises in store, waiting to trip us up? Yap, RR decided that hand does not look professional, but setting it explicitely to hand was supposed to continue to work afaik. Richard may know better. I seem to recall someone complaining about this vertical icon. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: For goodness sake!
Hi Klaus, Not entirely true. v2.5 prohibited set/get script and copy [obj] in password protected stacks, but clone has always been available. My points: [1] I can appreciate protecting script and copying access to prevent circumventing protected stacks, but clone can do nothing except duplicate in the same environment. bugzilla this ! I am still not clear, though, if your errors occur in password-protected stacks that are locked or unlocked. May be I missed a post. I will need this to work soon, so I'd like to test it out. [2] If dynamic scripting in protected stacks is being 'phased out', we need to be able to unlock, do whatever, then *re-set* the protection. This last step is not available, and until 2.5 was not required. Not only should it now be available, but it has become a CRITICAL command. vote for bug 546 :) Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: 2.61 Hand Cursor
Robert Brenstein wrote: What on earth has happened in this release? 'Set the cursor to hand' now results in a vertical splitter icon! Oh boy... This is not the robust and predictable environment to which I had become accustomed. It would help (or at least show willing) if such changes were flagged in the ReadMe notes. Do we have any other surprises in store, waiting to trip us up? Yap, RR decided that hand does not look professional, but setting it explicitely to hand was supposed to continue to work afaik. Richard may know better. I seem to recall someone complaining about this vertical icon. It's a bug. There was a spec which would have given the desired new behavior while maintaining backward compatibility, but apparently that spec was misunderstood or implemented in error. The new behavior is listed as a bug in Bugzilla: http://support.runrev.com/bugdatabase/show_bug.cgi?id=2032 No changes are planned for the MC IDE to compensate for this bug. At this time I'm expecting the initial spec to be implemented in the next Rev release, which will restore the behaviors of the last 14 years. I have no confirmation on this from RunRev, however, so your vote on the issue may help assure an adequate solution is pursued. -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: 2.61 Hand Cursor
What on earth has happened in this release? 'Set the cursor to hand' now results in a vertical splitter icon! I found this in Bugzilla. See Bugs 2032, 2103, 1846, 1807. According to the last one, things should be working as you expect them, so you may request reopening that bug. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: For xxx sake!
On 9/14/04 3:43 PM, Klaus Major [EMAIL PROTECTED] wrote: [1] I can appreciate protecting script and copying access to prevent circumventing protected stacks, but clone can do nothing except duplicate in the same environment. Yes, so it is kind of useless in protected stack... No, it's actually useful regardless of whether the stack is protected or not (it all depends on whether your app depends on being able to clone objects) - I think Hugh's point is that if the concern is one of security, it's not like copy, which can copy one object from one stack to another which might be used to copy an object from a protected stack to a non-protected stack; with clone, it only makes a copy on the same stack (protected or not), so there's no security risk. we need to be able to unlock, do whatever, then *re-set* the protection. This last step is not available, and until 2.5 was not required. Not only should it now be available, but it has become a CRITICAL command. Sorry, don't get this one either...? You mean setting the passkey, doing whatever, saving and closing the stack DOES remove the password/protection? No, what he's saying is that currently we have the ability to unlock a stack at runtime by setting the passkey. But you can't lock it back up again at runtime; the password will protect the stack *after* it's been closed and reopened (i.e. the passkey effect is temporary), but during the *session* while the stack is open, you can't re-protect it. This is something that is very much needed in order to close the loop on security. Ken Ray Sons of Thunder Software Web site: http://www.sonsothunder.com/ Email: [EMAIL PROTECTED] ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
