Purge Loop--Destroy Stack no working?

[Jerry Daniels]

Swami,

The better place to get support would be directly with  
support at daniels-mara.com rather than a public forum. We're not on  
this list every single day.

We need to get a bit more detail on this.

Best,

Jerry

On Nov 28, 2005, at 4:52 PM, Sivakatirswami wrote:

> Aloha, Jerry:
>
> more feed back.. this problem arose today again, open stack A call  
> "transcriber.rev" close... (destroy stack set to true)  try to open  
> a different stack with the same name... still in memory, purge loop  
> started happening again..
>
> I had actually previously completed deleted Object Gadget... it is  
> not even in the gadgets folder now  as of two weeks ago..
>
> I had to disable Constellation completely to continue work.. :- 
> (  (because it is so useful...)
>
> Sivakatirswami
>
>
> On Nov 14, 2005, at 2:13 AM, Jerry Daniels wrote:
>
>> Sivakatirswami,
>>
>> I thought about your problem so more and have the following  
>> observations, questions and recommendations.
>>
>> I don't think the problem is with the release version of  
>> Constellation you are using but, it is possible that there is a  
>> problem with one of Constellation's pre-release "buddies", Object  
>> Gadget.
>>
>> Do you have Object Gadget open when this is happening? There is a  
>> known issue with Object Gadget where it verifies its list and  
>> inadvertently keeps the stacks in memory because it likes to test  
>> every object's parent stack by its long stack name to see if it  
>> exists. Please test without Object Gadget and see if it makes any  
>> difference.
>>
>> Object Gadget it not released software, and it has known issues.  
>> For this reason, I only use Object Gadget when I need it for  
>> something and keep it close if I don't need it--and I have no  
>> difficulties with it. That's also why it is discounted so that it  
>> costs about two dollars right now. Once we get Object Gadget  
>> released, this will no longer be an issue (and the discounted  
>> price will go away, too).
>>
>> Please let me know how your test without Object Gadget goes--or  
>> how you do with discretionary use of it as indicated above.
>>
>> It would seem unlikely to me that your stacks are corrupted. My  
>> experience with corrupted stacks usually means the stack will not  
>> open and if it does it appears to have extremely sluggish behavior  
>> and slows down the IDE noticeably.
>>
>> Also, all of the products we sell are pretty stingy with doling  
>> out custom properties and there are preferences to prevent them  
>> from being used at all. I don't believe custom props would cause  
>> your problem, in any case.
>>
>> There are many people (I am becoming one) who prefer to store all  
>> data outside the stack--in a text file using XML or the like. Like  
>> others, when saving on close in the IDE, if something "unexpected"  
>> happens with the IDE, it can affect the process of saving and THEN  
>> corruption can take place. I haven't had problems with explicit  
>> saving in the IDE, whereas I have had problems with the implicit  
>> save you noted in your closeStack handler.
>>
>> Best,
>>
>> Jerry
>>
>> http://www.daniels-mara.com/products/constellation.htm
>> Scripts and properties in a tabbed editor!
>>
>> On Nov 13, 2005, at 10:36 PM, Sivakatirswami wrote:
>>
>>
>>> The past few days REv is repeatedly asking me if I want to purge  
>>> a stack in memory with the same name... Most of my stacks have
>>>
>>> on closestack
>>>    save this stack
>>> end close stack
>>>
>>> And for some reason, if Constellation is running, this puts me  
>>> into an infinite loop where Rev is unable to save (because there  
>>> is a stack in memory with the same name) ... I click save or  
>>> purge or cancel, it doesn't matter... the msg comes right back..
>>>
>>> if I don't boot constellation, I don't get into a loop but still  
>>> though all my stacks are set to Destroy on close, rev keeps  
>>> asking to purge a previously closed stack if I open another which  
>>> has the same name.
>>>
>>> I'm thinking something has been corrupted or a custom prop is  
>>> "stuck" somewhere that thinks these stacks are in memory when  
>>> they or not, or they are not being destroyed when they should  
>>> be... any ideas?  Rebooting Rev does not change the behavior.
>>>
>>> Sivakatirswami
>>>
>>>
>>>
>>> _______________________________________________
>>> use-revolution mailing list
>>> use-revolution at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your  
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>>
>>>
>>
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your  
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>