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 v
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
> 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/
__
> 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 d
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 dis
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
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 st
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
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 subscript
le "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 InfoCente
"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 allo
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 n
> 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...
Ke
Hello,
in a discussion in chatrev this night with Mark Schonewille (the runrev expert
from the Netherlands, which knew the "go stack " 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 bin
14 matches
Mail list logo
