Understanding 'the defaultStack'

classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Understanding 'the defaultStack'

Graham Samuel-4
I’m having a bit of difficulty understanding what the LC Dictionary says about ‘the defaultStack’. I had assumed that when a script executes

  go stack “myStack”

then the defaultStack would be set to “myStack” in all circumstances. This seems not to be the case. Jacque Gay recently told me:

> If a stack isn't toplevel and another stack with a lower mode is already open, I don't think it will become the defaultstack so you'd have to set that by script.

The Dictionary says:

> The defaultStack property is particularly useful in stacks opened in a mode other than an editable window (such as stacks that are being used as dialog boxes, palettes, ormenus). LiveCode's message box and editing palettes set the defaultStack property to the value returned by the topStack function before performing a stack action.

I am not sure what this means, but it doesn’t seem to me to to say explicitly what Jacque told me. Does the Dictionary need updating, or is it just my brain (slim chance)?

Graham
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Understanding 'the defaultStack'

mwieder
On 10/07/2016 12:56 AM, Graham Samuel wrote:

> I’m having a bit of difficulty understanding what the LC Dictionary says about ‘the defaultStack’. I had assumed that when a script executes
>
>   go stack “myStack”
>
> then the defaultStack would be set to “myStack” in all circumstances. This seems not to be the case. Jacque Gay recently told me:
>
>> If a stack isn't toplevel and another stack with a lower mode is already open, I don't think it will become the defaultstack so you'd have to set that by script.
>
> The Dictionary says:
>
>> The defaultStack property is particularly useful in stacks opened in a mode other than an editable window (such as stacks that are being used as dialog boxes, palettes, ormenus). LiveCode's message box and editing palettes set the defaultStack property to the value returned by the topStack function before performing a stack action.
>
> I am not sure what this means, but it doesn’t seem to me to to say explicitly what Jacque told me. Does the Dictionary need updating, or is it just my brain (slim chance)?

FWIW I think Jacque's explanation is the better of the two.
I think maybe LiveCode should ship <a copy of> her with every new build
of the dictionary.

--
  Mark Wieder
  [hidden email]



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Understanding 'the defaultStack'

Dr. Hawkins
On Fri, Oct 7, 2016 at 10:50 PM, Mark Wieder <[hidden email]> wrote:

> FWIW I think Jacque's explanation is the better of the two.
> I think maybe LiveCode should ship <a copy of> her with every new build of
> the dictionary.
>


on revBuildDictionary

clone Jacque

set the mainStack of it to stack revDictionary

end revBuildDictionary

:)
--
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Understanding 'the defaultStack'

J. Landman Gay
On 10/8/16 10:37 AM, Dr. Hawkins wrote:

> On Fri, Oct 7, 2016 at 10:50 PM, Mark Wieder <[hidden email]> wrote:
>
>> FWIW I think Jacque's explanation is the better of the two.
>> I think maybe LiveCode should ship <a copy of> her with every new build of
>> the dictionary.
>>
>
>
> on revBuildDictionary
>
> clone Jacque
>
> set the mainStack of it to stack revDictionary
>
> end revBuildDictionary
>
> :)
>

Well, I'm flattered guys, but unfortunately every time I clone myself
the variants lose track of each other and efficiency fragments. Git
might be better. ;)

But I'm not the right choice anyway because I don't know some of this
myself -- I have seen cases where the defaultstack doesn't follow the
rule, or uses some criteria I don't understand, where "go" doesn't set
the defaultstack automatically. I haven't yet pinned down a recipe.
Usually I just set it by script and move on.

I think that was the case with Graham's stack too. Some quirky rule is
interfering, or else it's a bug. If so, it's been there a long time.

It would be great if someone could look at the source code and give us a
list of how the engine determines the defaultstack. Then I could write
it down, wait until everyone else forgets about it, and then post it
like I know everything...

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Understanding 'the defaultStack'

Richard Gaskin
J. Landman Gay wrote:

 > I have seen cases where the defaultstack doesn't follow the rule,
 > or uses some criteria I don't understand, where "go" doesn't set
 > the defaultstack automatically. I haven't yet pinned down a recipe.
 > Usually I just set it by script and move on.

The rule Dr. Raney gave me is that the defaultStack is the topmost
visible stack of the lowest mode.

Beyond that I believe the only exceptions are normal scoping rules, such
as a script in a palette stack referring to a button will try to resolve
that reference in itself unless some other stack is specified.  But even
then, calling "the defaultStack", regardless of where it's called from,
should reflect that one rule unless you've explicitly sat it to
something else.

If there are indeed exceptions it would be handy to find them and fix
them.  Having a single rule for the defaultStack makes it very useful,
and Raney'a definition seems logical.  If there are exceptions we might
want to think long and hard about keeping them, as they may well be just
regressions that crept in somewhere over the years.  I can't think of a
case offhand where anything other than the one rule would be desirable.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Understanding 'the defaultStack'

Monte Goulding-2

> On 9 Oct 2016, at 7:22 AM, Richard Gaskin <[hidden email]> wrote:
>
> The rule Dr. Raney gave me is that the defaultStack is the topmost visible stack of the lowest mode.

^ that’s pretty close but there are some other things that come into play. It’s a bit of a slippeyr fish.

The defaultStack is set when executing a script to the stack the script is in until it is changed by that script. After the script runs it will be reset to the previous value unless the previous defaultStack happened to be deleted.

Some events cause the defaultStack to be set to the topStack. The default stack is reset in the main engine loop to the stack Richard described.

Cheers

Monte

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Understanding 'the defaultStack'

J. Landman Gay
In reply to this post by Richard Gaskin
On 10/8/16 3:22 PM, Richard Gaskin wrote:
> The rule Dr. Raney gave me is that the defaultStack is the topmost
> visible stack of the lowest mode.

I thought visibility might impact it (I believe that's the case with
Graham's stack) so I did some quick tests and even though there was a
visible mode-1 topstack, going to the invisible one did change the
defaultstack. Thus, my curiosity.

I.e.:

Stack One
visible
topstack
mode 1


command: go stack stackTwo

stackTwo
visibility false
mode 1

command: put the defaultstack
-> stackTwo


So...?

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Understanding 'the defaultStack'

pmbrig
I have a stack that in one place and one place only when the script calls for “ask … with … as sheet” sheets the ask dialog and then it promptly loses focus. If I try to type a replacement for the default text or hit <return> to affirm the default text, nothing happens — the dialog has lost focus as one can see by the hilite color for the text and the lack of blue background for the “OK” button. I have to click in the text field, then do what I want with the dialog. Have not tracked this down. At this point I can’t recall which “ask…” command this occurs in so I can post that section of script, but it only happens in that one place. I don’t know if this is related to the defaultstack issue.

— Peter

Peter M. Brigham
[hidden email]


> On Oct 8, 2016, at 4:54 PM, J. Landman Gay <[hidden email]> wrote:
>
> On 10/8/16 3:22 PM, Richard Gaskin wrote:
>> The rule Dr. Raney gave me is that the defaultStack is the topmost
>> visible stack of the lowest mode.
>
> I thought visibility might impact it (I believe that's the case with Graham's stack) so I did some quick tests and even though there was a visible mode-1 topstack, going to the invisible one did change the defaultstack. Thus, my curiosity.
>
> I.e.:
>
> Stack One
> visible
> topstack
> mode 1
>
>
> command: go stack stackTwo
>
> stackTwo
> visibility false
> mode 1
>
> command: put the defaultstack
> -> stackTwo
>
>
> So...?
>
> --
> Jacqueline Landman Gay         |     [hidden email]
> HyperActive Software           |     http://www.hyperactivesw.com
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Understanding 'the defaultStack'

Richard Gaskin
In reply to this post by J. Landman Gay
J. Landman Gay wrote:

> On 10/8/16 3:22 PM, Richard Gaskin wrote:
>> The rule Dr. Raney gave me is that the defaultStack is the topmost
>> visible stack of the lowest mode.
>
> I thought visibility might impact it (I believe that's the case with
> Graham's stack) so I did some quick tests and even though there was a
> visible mode-1 topstack, going to the invisible one did change the
> defaultstack. Thus, my curiosity.
>
> I.e.:
>
> Stack One
> visible
> topstack
> mode 1
>
>
> command: go stack stackTwo
>
> stackTwo
> visibility false
> mode 1
>
> command: put the defaultstack
> -> stackTwo
>
>
> So...?

Personally I'd consider that a bug.  Even if visibility was never part
of a formal definition, so much of the learnability of xTalk rests on
being able to predict outcomes based on what we see.  The layering of a
window visibly changes if a window above it becomes hidden, all the way
down to how the OS renders the drag region.

To me it seems logical that an invisible window should be expected to
require special handling if another window of the same mode is visible.

I can't think of a case where the behavior you've documented would be
either anticipatable or desirable.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Understanding 'the defaultStack'

Graham Samuel-4
In reply to this post by Monte Goulding-2
Monte, thanks for that, but even your expert intervention this doesn't quite say what the rules actually are. I think the Dictionary should be revised to give a complete account.

Cheers

Graham

Sent from my iPad

> On 8 Oct 2016, at 21:51, Monte Goulding <[hidden email]> wrote:
>
>
>> On 9 Oct 2016, at 7:22 AM, Richard Gaskin <[hidden email]> wrote:
>>
>> The rule Dr. Raney gave me is that the defaultStack is the topmost visible stack of the lowest mode.
>
> ^ that’s pretty close but there are some other things that come into play. It’s a bit of a slippeyr fish.
>
> The defaultStack is set when executing a script to the stack the script is in until it is changed by that script. After the script runs it will be reset to the previous value unless the previous defaultStack happened to be deleted.
>
> Some events cause the defaultStack to be set to the topStack. The default stack is reset in the main engine loop to the stack Richard described.
>
> Cheers
>
> Monte
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Understanding 'the defaultStack'

Monte Goulding-2

> On 9 Oct 2016, at 9:09 AM, Graham Samuel <[hidden email]> wrote:
>
> Monte, thanks for that, but even your expert intervention this doesn't quite say what the rules actually are. I think the Dictionary should be revised to give a complete account.


Expert intervention might be overestimating things a bit.

Yes it would probably be good if someone improved the docs if it’s causing confusion. For what it’s worth I personally never depend on the defaultStack being anything unless I explicitly set it and I usually only do that when I want to create objects on a stack from some script that isn’t on it.

Cheers

Monte
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Understanding 'the defaultStack'

Jeanne A. E. DeVoto
In reply to this post by J. Landman Gay
At 3:54 PM -0500 10/8/2016, J. Landman Gay wrote:
>I thought visibility might impact it (I believe that's the case with
>Graham's stack) so I did some quick tests and even though there was
>a visible mode-1 topstack, going to the invisible one did change the
>defaultstack. Thus, my curiosity.


I quote:  "The topStack is the frontmost stack with the lowest mode."

The mode runs from 0 to 13 (unless someone's added some modes
lately), and invisible isn't one of the modes-a toplevel visible
stack has the same mode as a toplevel invisible one.

(I don't claim this makes actual sense, mind you....)
--
jeanne a. e. devoto
[hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Understanding 'the defaultStack'

Monte Goulding-2

> On 9 Oct 2016, at 10:15 AM, Jeanne A. E. DeVoto <[hidden email]> wrote:
>
> (I don't claim this makes actual sense, mind you....)

What about this:

go invisible stack
do some stuff depending on the defaultstack being changed to the stack
show stack
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Understanding 'the defaultStack'

Monte Goulding-2
In reply to this post by Monte Goulding-2
Hi Folks

I just had a look into the source and here’s the but in the go command causing confusion:

    if (t_stack->getmode() == WM_TOP_LEVEL || t_stack->getmode() == WM_TOP_LEVEL_LOCKED)
        MCdefaultstackptr = t_stack;

What this means is that unless the mode of the stack is topLevel (1) or topLevel + cantModify (2) the defaultStack is not changed by the go command.

Cheers

Monte
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Understanding 'the defaultStack'

J. Landman Gay
In reply to this post by Jeanne A. E. DeVoto
That's what I saw too in my experiment, but I was issuing commands from the
message box. When Graham did a "go stack invisibleStack" the defaultstack
didn't change to it.

From what Monte said, I'm guessing that Graham's running script was in the
original stack and maybe the engine hadn't done its swap yet.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com



On October 8, 2016 6:17:48 PM "Jeanne A. E. DeVoto"
<[hidden email]> wrote:

> At 3:54 PM -0500 10/8/2016, J. Landman Gay wrote:
>>I thought visibility might impact it (I believe that's the case with
>>Graham's stack) so I did some quick tests and even though there was
>>a visible mode-1 topstack, going to the invisible one did change the
>>defaultstack. Thus, my curiosity.
>
>
> I quote:  "The topStack is the frontmost stack with the lowest mode."
>
> The mode runs from 0 to 13 (unless someone's added some modes
> lately), and invisible isn't one of the modes-a toplevel visible
> stack has the same mode as a toplevel invisible one.
>
> (I don't claim this makes actual sense, mind you....)
> --
> jeanne a. e. devoto
> [hidden email]
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Understanding 'the defaultStack'

Monte Goulding-2
In reply to this post by Monte Goulding-2
I suspect the fact that go sets the defaultStack (if it is topLevel) and neither clone stack or create stack do regardless of mode also needs to be documented somewhere. I wonder if go altering the defaultStack should be added to the bug db as an anomaly report? It’s certainly a non-obvious side effect of the command.

> On 9 Oct 2016, at 10:26 AM, Monte Goulding <[hidden email]> wrote:
>
> Hi Folks
>
> I just had a look into the source and here’s the but in the go command causing confusion:
>
>    if (t_stack->getmode() == WM_TOP_LEVEL || t_stack->getmode() == WM_TOP_LEVEL_LOCKED)
>        MCdefaultstackptr = t_stack;
>
> What this means is that unless the mode of the stack is topLevel (1) or topLevel + cantModify (2) the defaultStack is not changed by the go command.
>
> Cheers
>
> Monte
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Understanding 'the defaultStack'

Jeanne A. E. DeVoto
In reply to this post by Monte Goulding-2
At 10:26 AM +1100 10/9/2016, Monte Goulding wrote:

>I just had a look into the source and here's the but in the go
>command causing confusion:
>
>     if (t_stack->getmode() == WM_TOP_LEVEL || t_stack->getmode() ==
>WM_TOP_LEVEL_LOCKED)
>         MCdefaultstackptr = t_stack;
>
>What this means is that unless the mode of the stack is topLevel (1)
>or topLevel + cantModify (2) the defaultStack is not changed by the
>go command.


OK, thar seems like a bug to me. If the only stacks open are
palettes, for example, then go should make the target stack the
topStack (and hence the defaultStack, since no stacks of lower mode
are open).

(In practice, I usually adopt the strategy of setting the
defaultStack explicitly or else targeting everything to the specific
stack I want. I think of the defaultStack as being pretty fragile.)

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Understanding 'the defaultStack'

Monte Goulding-2

> On 9 Oct 2016, at 10:51 AM, Jeanne A. E. DeVoto <[hidden email]> wrote:
>
> OK, thar seems like a bug to me. If the only stacks open are palettes, for example, then go should make the target stack the topStack (and hence the defaultStack, since no stacks of lower mode are open).

I can’t help thinking that go touching the defaultStack at all is bug or rather a bad idea in the first place that probably can’t be changed now. Just because you opened a stack does not necessarily mean you want to target the rest of your script to the stack you opened.
>
> (In practice, I usually adopt the strategy of setting the defaultStack explicitly or else targeting everything to the specific stack I want. I think of the defaultStack as being pretty fragile.)

Yes that’s what I do to as the script is much clearer if you explicitly set the defaultStack anyway.

Cheers

Monte
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Understanding 'the defaultStack'

Monte Goulding-2
In reply to this post by Jeanne A. E. DeVoto

> On 9 Oct 2016, at 10:51 AM, Jeanne A. E. DeVoto <[hidden email]> wrote:
>
> OK, thar seems like a bug to me. If the only stacks open are palettes, for example, then go should make the target stack the topStack (and hence the defaultStack, since no stacks of lower mode are open).

Thinking on this some more I don’t think you can do what you are suggesting here. Go currently sets the defaultStack to the target stack if it is topLevel. If it set the defaultStack to the topStack it would depend on the current state of the environment whether the defaultStack is the stack being opened by go after the command while at the moment it just depends on the mode of the stack being opened.

Indeed let’s say you have stack A that opens stack B and stack B that opens stack C in its preOpenCard handler. At the moment:

stack A - is defaultStack in its own script
go stack B
  stack B preOpenStack - stack B now defaultStack in its own script
  go stack C
     stack C preOpenStack - stack C no defaultStack in its own script
  stack B preOpenStack continues but stack C is now the defaultStack
back to stack A script and now stack B is the defaultStack

But if you change it to set to the topStack then when you go back to the stack A script then stack C will be the defaultStack.

Cheers

Monte
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Understanding 'the defaultStack'

J. Landman Gay
In reply to this post by Monte Goulding-2
On October 8, 2016 7:06:15 PM Monte Goulding <[hidden email]> wrote:

> I can’t help thinking that go touching the defaultStack at all is bug or
> rather a bad idea in the first place that probably can’t be changed now.
> Just because you opened a stack does not necessarily mean you want to
> target the rest of your script to the stack you opened.


Actually that's been the whole xtalk metaphor forever and you're right that
changing it would break a lot of stacks. When you go to a stack, it becomes
"this stack", and you are on "this card" and you expect your script to act
on the controls there. It dates back to HC where there was only a single
stack open at any time and no confusion was possible. With the introduction
of multiple windows, the behavior stayed the same and if you want to
address objects in the original stack, you need to use long object
references or set the defaultstack yourself.

I'm okay with how it works now, but I want to know what the exceptions are.
I think I'm starting to get the idea.

Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
123