Page 1 of 1

Stacks getting contaminated with other stacks

Posted: Sat Jul 31, 2010 9:17 pm
by Judson
From time to time now one of the "start using..." stacks ends up getting contaminated with one of the production stacks.

What I mean is that it seems to acquire all the content of one of the production stacks and then Revolution gets all confused as to where changes are.

I can tell this is happening because the size of the "start using" stack is about 16 kilobytes and the production stack is on the order of 37 megabytes. So when the "start using" stack ends up the same size coupled with the behavior..., well you get the picture.

1) What is happening to cause this?

2) When it does happen there appears no way to clear out the problem. I seem to have to create a brand new stack, copy all the code into it, and start afresh.

Any ideas on this one?

Re: Stacks getting contaminated with other stacks

Posted: Sat Jul 31, 2010 11:10 pm
by Mark
Judson,

My first hunch is that you have a script in your library stack that responds to the creation, deletion or updating of objects. The information you have is very sparse. Could you figure out when exactly the problem occurs?

Best,

Mark

Re: Stacks getting contaminated with other stacks

Posted: Sat Jul 31, 2010 11:21 pm
by Curry
See also: defaultStack

Re: Stacks getting contaminated with other stacks

Posted: Sat Jul 31, 2010 11:33 pm
by Judson
Hummm, I don't see that.

As for defaultstack, that command is not used.

I can't identify when the problem materialized.

There seems to be something where stacks can have names which are different than their filenames and I wonder if that is a contributing factor.

Re: Stacks getting contaminated with other stacks

Posted: Sat Jul 31, 2010 11:42 pm
by Mark
Judson,

Normally, using file names to refer to stacks doesn't cause any problems. What are you doing with regard to file names exactly?

Best regards,

Mark

Re: Stacks getting contaminated with other stacks

Posted: Sat Jul 31, 2010 11:46 pm
by Curry
Libraries have to be written carefully with regard to stack references. Perhaps the library code is the culprit.