Hi,
For what it's worth, I think that all that needs to be changed is to
rename or alias the delete stack command to purge, in the meantime
I'd create a function/handler called "PurgeStack" that does it.
One thing that struck me is that if you were to want to grab a lot of
cp's from a stack, as in:
put the cp1 of stack_long_name into x1
put the cp2 of stack_long_name into x2
put the cp3 of stack_long_name into x3
put the cp4 of stack_long_name into x4
put the cp5 of stack_long_name into x5
etc.
Then surely if you purged it from memory after each access then it
would take a very long time to grab all the data, especially if the
stack were large in size and their were a lot of data.
IMO tho, the better way around it would be to introduce a concept of
a read-only stack, it could be handled in many ways, this would be
one of them:
set the stackStatus of stack_long_name to "readonly"
(now read the values as above)
When the cp is set, it would cause the stack to be read into memory
and it's status to be set to "readonly". An error would occur if the
stack were already open (e.g. status of "readwrite"). If in read only
mode and an attempt to write to the stack is made, then an error
would occur (maybe controlled by another (global) cp). If the stack
were opened then it's status would become "read-write" and since it's
already in memory, it would be quicker.
Having said all that, I do it a different way, since I fell foul of
the problems you are experiencing.
My approach it to do this:
set the visible of stack_long_name to false
set the cpFlagGetData of stack_long_name to true
open stack stack_long_name
--Call a function (using value()) in the stack that causes it to send
it's data back to the calling stack
--by calling a predefined "AcceptData" function in the calling stack
set the cpFlagGetData of stack_long_name to false
save stack stack_long_name
close stack stack_long_name
(I just put all this in a function)
Then if the stack is opened with the cpFlagGetData set to false, I
just make it visible in the preOpenStack handler.
Now I have combined all this into my ISM module so it all happens
automatically, but that's how I did it before I wrote ISM.
All the Best
Dave
On 1 Nov 2006, at 07:18, Chipp Walters wrote:
I'm going to have to agree with Dave and Trevor. I've always thought
destroyStack comes into play only when closing stacks. If set to
true, the
stack is purged from memory (usually). I pretty much always use an
explicit
'delete stack "xyz"' when I want to make sure a mainstack is closed.
And like Dave, I, too, use stacks as repositories for data.
Richard, I'm not
sure I understand your comment about parsing the stack file format.
I'm
pretty sure Dave is just talking about using stacks to store data in--
separate from the business logic of the application. I typically use:
go inv stack "xyz" when I want to access data from a stack. Though
I also
frequently check a custom prop for versioning, too. In both cases, I'm
careful to 'delete' the stack when done.
I think Dave's point regarding reading customProps from a stack, doing
something with them, then saving them to the stack and finally
closing it,
is common among many of us who use customProps to hold data. Finally,
Richard, I know you use the fine MC IDE and have a whole sweet(sp)
of tools
you use. But, in the Rev IDE, I'm with Jacque and one of the first
things I
do is set the default pref for destroyStack to true. It just works
better. I
think it should be the default.
I guess it's one of choice. Mine is to leave it like it is, but I
do agree
some naming nomenclature may be necessary. I particularly like the
notion of
a 'purge stack' command.
-Chipp
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
