Re-2: persistent objects in runrev (howto)
Hello Ken yes - you can copy objects (buttons, groups) INTO password protected stacks, but not copy objects FROM them. Coming from Toolbook I had to realize and accept that ... runrev password protection protects stacks against * copiing objects FROM it * editing passwords It does not protect the stack against * copying objects INTO it (including scripts in this objects) * deleting objects within it, * moving around * reading/writing custom properties of stacks or objects etc. This causes the behavior that you can copy an object (even a background coming in front of the event hierarchy) INTO a password protected stack - but you cannot copy a modified object back then without putting the passkey ... Because I have to copy the objects from my working stack to the tempStack first I have to use stacks without runrev password protection (to copy objects FROM) for my concept of persistent objects. With the concept of my own encrypted stacks I can load from the standalone (with an embedded stack which is password protected and includes the aniDecrypt function) we have talked about in chatrev I now am able to do what I want. This would be the concept: put URL christmas.aniweb into chistmas; go stack aniDecrypt(christmas); Regards, Franz Original Messageprocessed by David InfoCenter Subject: Re: persistent objects in runrev (howto) (13-Okt-2008 18:16) From:Ken Ray [EMAIL PROTECTED] To: [EMAIL PROTECTED] This allows me to use stacks and any copy object from stack to stack command without hesitating about the password protection of the stack. Solving some problems in one step. So you're saying that you can copy an object into a password protected stack this way? Just trying to clarify... Ken Ray Sons of Thunder Software, Inc. Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.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 To: 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
Re-2: persistent objects in runrev (howto) + Q: unprotected stacks in standalones
Hello Chipp, The experienced users seem to have had this solution (the old suckUp spitOut trick) since years I am so proud of since the weekend. Exactly thats it. Because I even could embed some unprotected stacks I would use in this way in standalones instead of putting it in a separated .rev file: A question to the experienced: The old 2.2.1 standalones have been #!/bin/sh encapsulated stack files and the old decompile script from the list could decompile the stacks from the standalones (the stacks stay password protected to be shure). The standalones now seem to be changed in format and technique (I checked this on 2.7 a year ago on linux and win) and the decompile script from the eldest does not work anymore. Q: Is it possible to decompile current standalones with such a short script? (Please not the answer: you can decompile any program ... ;-) I am no assembler. Regards, Franz Mit freundlichen Grüßen Franz Böhmisch [EMAIL PROTECTED] http://www.animabit.de GF Animabit Multimedia Software GmbH Am Sonnenhang 22 D-94136 Thyrnau Tel +49 (0)8501-8538 Fax +49 (0)8501-8537 on mouseUp answer file Standalone if it is cancel then exit to top put url (binfile:it) into tStack repeat forever -- there's more than one stackfile in there which isinteresting ;-) put offset(#!/bin/sh,char 10 to -1 of tStack) into tOff if tOff = 0 then exit repeat put char tOff+9 to -1 of tStack into tStack end repeat ask file Stack if it is cancel then exit to top set the fileType to RevoRSTK put tStack into url (binfile:it) answer conversion finished with OK end mouseUp Regards, Franz Original Messageprocessed by David InfoCenter Subject: Re: persistent objects in runrev (howto) (13-Okt-2008 19:48) From:Chipp Walters [EMAIL PROTECTED] To: [EMAIL PROTECTED] Ken, The way I read it-- it's the old suckUp spitOut trick but encrypting the stack beforehand. The idea being it's not necessary to password protect the stack as anyone trying to read the file format won't be able to make sense of it. Therefore, after 'spitting out' you can use it just like any non-password protected stack. Perhaps I'm wrong, but that's what I get from the rather vague post. -Chipp ___ 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 To: 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
Re: Re-2: persistent objects in runrev (howto) + Q: unprotected stacks in standalones
Hi Franz, The format has changed, and to my knowlege there is not decompile stack or script available for it. Sorry. ___ 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
Re: Re-2: persistent objects in runrev (howto)
Franz wrote: Coming from Toolbook I had to realize and accept that ... runrev password protection protects stacks against * copiing objects FROM it * editing passwords It does not protect the stack against * copying objects INTO it (including scripts in this objects) * deleting objects within it, * moving around * reading/writing custom properties of stacks or objects etc. This causes the behavior that you can copy an object (even a background coming in front of the event hierarchy) INTO a password protected stack - but you cannot copy a modified object back then without putting the passkey ... Yes, Rev's script protection does not attempt to hinder any form of alteration of the message path, it merely prevents scripts from being read. If you could copy an object from a protected stack to an unprotected one, its scripts would become exposed. There is a request to support password-protection of any object, not just stacks: http://quality.runrev.com/qacenter/show_bug.cgi?id=659 (Note to RunRev: I am not soliciting votes here, just noting an existing report that is relevant to the conversation. Whether or not someone decides to add their votes for it is entirely at their own discretion. The readers here are not my zombie legion. g) Because I have to copy the objects from my working stack to the tempStack first I have to use stacks without runrev password protection (to copy objects FROM) for my concept of persistent objects. 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, e.g: -- In copied object: on mouseDown DoSpecialMouseDownThang end mouseDown -- In some central location: on DoSpecialMouseDownThang -- all the cool stuff your object does -- goes here end DoSpecialMouseDownThang Not only does this provide complete protection for your proprietary algorithms, but it also makes the code lighter in the copied objects, minimally reducing memory usage. But more useful is that it keeps the complex stuff in one place, so it can be maintained and enhanced without needing to make sure that all copies of the script are kept in synch. Just curious: What options does Toolbook provide for script protection? -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.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
