Re-4: persistent objects in runrev (howto)
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
Re: persistent objects in runrev (howto)
Hello Andre, Thanks Andre for your info: Nothing new under the sun (Qohelet) I had to learn this method of storing objects as binaries by trial and discussion, because I did not read it in newsletters or sth similar. But I am glad to have realized it - late but I did ;-) As a result of our discussion in further versions of runrev I would expect a runrev function to export only the selected objects into a file and restore it, like existing moduls in perl,python,java do. And perhaps this could be done with protection immediately. Or does this exist and I did not realize it? sth similar like export/save group content into URL binfile:content.1.aniweb using passkey mykey import/restore group content from URL binfile:content.1.aniweb using passkey mykey instead of create tempstack copy object xyz from stack contentdesigner to tempstack save tempstack as ... delete tempstack open tempstack copy object xyz from tempstack into currentstack delete tempstack (for not running into memory problems with many open tempstacks). 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 ___ 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: persistent objects in runrev (howto)
As a result of our discussion in further versions of runrev I would expect a runrev function to export only the selected objects into a file and restore it, like existing moduls in perl,python,java do. And perhaps this could be done with protection immediately. Or does this exist and I did not realize it? No, it does not exist at the moment AFAIK; you have to use the tempstack approach as you've outlined. I would *love* to have this ability though... 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
OT: Sth (was Re: Re-4: persistent objects in runrev (howto))
objects with empty scripts, I have sth like: Franz, this is the second time you've used sth as a word (two different posts)... just curious, what does it mean? 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
Re: OT: Sth (was Re: Re-4: persistent objects in runrev (howto))
Hi Ken, objects with empty scripts, I have sth like: Franz, this is the second time you've used sth as a word (two different posts)... just curious, what does it mean? SomeTHing, altough I'm not Franz :-) Ken Ray Sons of Thunder Software, Inc. Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ Regards Klaus Major [EMAIL PROTECTED] http://www.major-k.de ___ 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: persistent objects in runrev (howto)
H. Seems like a simple enough function/command to write? And it should execute very fast as well. I imagine a library with a set of functions to do this may be helpful for some. ___ 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)
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
Re: persistent objects in runrev (howto)
Hello, I think we've been doing this for some years, right? I've stored not only stacks but whole applications inside customprops and other binary containers. This is actually quite common, people store fonts, images, all kinds of assets, even stacks in binary blobs. With the RevZip we can even store whole folder structures inside a custom property. Now with Revolution 3.0 cute arrays, we can create object like structures and persisting them is just a matter of some back/front script loading and saving them. You can save stuff to sqlite binary blobs or valentina, and store your stacks in your own embeded database... now if we only had parent scripts or someway to tie script events to accessing array elements, then it would be cool Am I missing something? andre On Mon, Oct 13, 2008 at 6:57 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello, in a discussion in chatrev this night with Mark Schonewille (the runrev expert from the Netherlands, which knew the go stack binary data trick) we could realize that the storage of objects from runrev as persistent objects and the reload into runrev applications even could be done using just binary data and not only a valid rev stack file with .rev extension. Short updated abstract in http://www.animabit.de/runrev/persistentobjects.html put URL http://server/xyz.data; into test # with xyz.data to be the result of a routine: # save stack xyz to URL xyz.data put mydecryproutine(test) into stackobject go invisible stackobject copy control 1 of stack stackobject into stack myprog ... 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. Regards, 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 ___ 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 -- http://www.andregarzia.com All We Do Is Code. ___ 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
persistent objects in runrev (howto)
Hello, in a discussion in chatrev this night with Mark Schonewille (the runrev expert from the Netherlands, which knew the go stack binary data trick) we could realize that the storage of objects from runrev as persistent objects and the reload into runrev applications even could be done using just binary data and not only a valid rev stack file with .rev extension. Short updated abstract in http://www.animabit.de/runrev/persistentobjects.html put URL http://server/xyz.data; into test # with xyz.data to be the result of a routine: # save stack xyz to URL xyz.data put mydecryproutine(test) into stackobject go invisible stackobject copy control 1 of stack stackobject into stack myprog ... 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. Regards, 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 ___ 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: persistent objects in runrev (howto)
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
Re: persistent objects in runrev (howto)
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
