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
[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
_______________________________________________
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
