Purge Loop--Destroy Stack no working?

Sivakatirswami katir at hindu.org
Mon Nov 28 17:52:33 EST 2005


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
>




More information about the use-livecode mailing list