Close Stack Cleanup
tore.nilsen at me.com
Thu Feb 4 17:50:45 EST 2021
Performing the clean up in preOpenStack makes it happen before the stack is visible, at least according to the dictionary.
"Unlike openStack <>, preOpenStack handlers <> are executed <> before the stack window <> appears. Because of this, the preOpenStack handler <> is a good place to put code that adjusts the size, position, and appearance of objects <>; the changes are made before the stack <> appears."
My experience is that this is true.
> 4. feb. 2021 kl. 23:43 skrev Bob Sneidar via use-livecode <use-livecode at lists.runrev.com>:
> Thanks for the response Curry and Tore.
> The reason I clean up at close is because when I open the stack the next time I do not want to remains of what I was doing before to show. It’s a small point but it look cleaner if the first time opening the stack there is nothing in the fields. All attempts to hide the stack then clear it before making it visible have been iffy.
> I guess what I need is a message or series of messages that get generated BEFORE the stack is closed.
> I have this in the only card in my stack:
> on closeStackRequest
> save this stack
> pass closeStackRequest — this has a breakpoint
> end closeStackRequest
> I have a breakpoint on the pass statement. When clicking the red dot I get asked if I want to save the stack. For whatever reason, for me the closeStackRequest is NOT getting sent to the current card!
> Bob S
>> On Feb 4, 2021, at 1:23 PM, Curry Kenworthy via use-livecode <use-livecode at lists.runrev.com> wrote:
>>> I am trying to clean up my stack (i.e. clear the fields),
>>> then save it when I close it
>> This is a good topic for LiveCode learners; I'm chiming in....
>> I often do something similar - but with an important difference:
>> I perform cleanup when I save. I do NOT force an auto save.
>> (More on that later.)
>>> BY ANY MEANS. That means by script, by menu OR by clicking the red dot
>>> (of for WIN users the red X) in the title bar.
>>> I need this to work in the IDE as well as in standalone.
>> So, let's halt at this point and take inventory of your desires!
>> You want to trap at least 3 methods of initiating a close action.
>> (Tally: 3)
>> Furthermore, IDE versus Standalone is an extra complexity.
>> I don't like that, but it is the unfortunate reality.
>> So I'm accounting for that extra complexity via a "+" designation!
>> (Tally: "3+")
>> Now jumping ahead a bit to make a connection:
>>> If I use “CloseStack” instead
>> Remember our tally of "3+" Actions?
>> The word "instead" suggests you're assuming a SINGLE trap.
>> Everyone here should know my KISS philosophy: less is better.
>> 3 birds with one stone is superior; I'm always harping on that.
>> But then again, in this case you have 3+ birds! :)
>> I'd hazard a guess on 2 traps - that's my experience for similar cases.
>> (But if one will work, use one.)
>>> You would think closeStackRequest gets sent when I
>>> click the red dot or X. You would be mistaken.
>> Actually I would NOT be mistaken, as long as we're talking about the X,
>> and the stack has been named/saved at least once. Just tested it!
>> But among the "extra complexity" I mentioned, if the stack is dirty,
>> the IDE will trap the close action at the front, BEFORE you get it.
>> It can still fire, but AFTER you dance around a bit with the IDE.
>> (Important to note that's the IDE; closeStackRequest does respond.)
>> To succeed in the IDE, you may indeed need to use closeStack.
>> But that's probably "with" not "instead" of closeStackRequest!
>> We can still follow KISS and avoid duplicating code,
>> via modularity - the 2 traps can call a common set of code.
>> Using params or other means to handle the differences in the 2/3 cases.
>>> I just want it to be saved. I can force quit if I mess something up.
>> I DISCOURAGE using a custom auto-save and resorting to force quit.
>> If you implement an auto-save, do it very well.
>> (And done well, a force-quit would not likely be Plan A for reverting.)
>> But I encourage cleanup when saving or when closing. I do it constantly.
>> It just requires a set of trap(s) that does spring for the 3 actions.
>> You're half way there, just think "AND" not "instead" to finish it!
>> Best wishes,
>> Curry Kenworthy
>> Custom Software Development
>> "Better Methods, Better Results"
>> LiveCode Training and Consulting
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
More information about the use-livecode