REALLY close stack - no, really

[John Rule]

I suppose I am referring more to the 'Purge' dialog that comes up at
unexpected times. In Revolution, this almost always resulted in a crash, and
losing what I was working on (no matter what I pressed). In MC, it at least
let you 'really' cancel most of the time. As far as I can tell this is
related to having two main stacks with the same name in memory (or, one in
memory, and you are trying to load another with the same name).

This happens (in my case) because I like to save revisions of my work, so I
save a stack with a revision name, and that does not reflect the actual
window name...there is now a conflict when I try to load two revisions (for
cutting and pasting, comparison, etc.). I have modified the MC IDE enough to
change the actual name of my window when I save (mainstack), and there is
only the occasional problem when I circumvent my own protection  ;-)

If I need to keep stacks (or information) in memory, I prefer to do it
myself. Maybe an option to turn this checking off? Why doesn't the engine
check the window ID anyway rather than the name? Why shouldn't I be able to
have two main windows with the same name? Is this off topic?

JR


> Date: Tue, 15 Jun 2004 21:23:58 -0700
> From: Richard Gaskin <ambassador at fourthworld.com>
> Subject: Re: REALLY close stack - no, really
> To: How to use Revolution <use-revolution at lists.runrev.com>
> Message-ID: <40CFCB5E.70807 at fourthworld.com>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> John Rule wrote:
>
> > Does this feature actually benefit anyone? In all of the years I have
used
> > MC or RR I have been fighting this 'Purge' annoyance (and I have lost
some
> > work because of it). I now just make sure that the 'Destroy' attributes
are
> > set (destroy window and destroy stack)...this works 'mostly', but not
> > always. I wish it would just be taken out of the engine itself....when I
> > close a window, I am closing it! If I want to keep it in memory, I will
> > 'hide' it myself.
>
> I agree that destroyStack should be on by default, but I very much
> appreciate that it gives us control over how we manage memory.
>
> Just today I was working on a system in which it's necessary to keep a
> database distributed among 36 stackfiles, but each one is relatively
> small so collectively they don't take up much RAM.  Moreover, with the
> destroyStack set to true the lookups across multiple stack files slow to
> a crawl, but with it off those lookups are lightning fast but, unlike
> haaving them open and hidden, I never have to worry about messaging
> issues or special-casing them to exclude them from my Windows menu, etc.
>
> In contrast, I have another app I've been working on which support
> multiple documents, and for that one I have the destroyStack set to true
> to completely "put down" a document when it's closed, so it completely
> mirrors traditional application behaviors.
>
> When you cut your teeth on other systems without such options, yes,
> learning how to use destroyStack effectively takes about as long as the
> first time you learned about cantAbort or cantModify or any other useful
> stack property.
>
> Ah, but once you get the hang of it the world is your oyster. :)
>
> FWIW, while I've seen many questions on both of the Transcript lists
> about how to use destroyStack effectively, in practice I've found it to
> be very reliable.  It's an old property that's been field-tested in
> hundreds of apps for about a decade, so if there were issues with its
> reliability they would likely have been more prevalent.
>
> I say this not to suggest that you're not seeing what you're seeing. On
> the contrary, my aim is simply to help get a better understanding of
> what you're seeing.
>
> It may be the case that a bug was introduced in more recent versions
> that has made destroyStack less reliable.  It may also be that what
> you're seeing is a function of the IDE and not the engine.
>
> For the latter, you can use the Message Box to verify a property
> setting, or more conveniently you could double-check it with something
> like my 4W Props utility (available in RevNet).
>
> If indeed the property is set as the IDE shows but is not being honored
> by the engine,  if you can toss together a simple example that
> demonstrates this anomaly and post it to Bugzilla it'll likely be fixed
> ASAP.  The destroyStack property plays such a key role in so many system
> designs that it would be unlikely that such a bug would be tolerated for
> long if a good recipe is included with the bug report.
>
> -- 
>   Richard Gaskin
>   Fourth World Media Corporation