Understanding 'the defaultStack'

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

Re: Understanding 'the defaultStack'

J. Landman Gay
It's only non-obvious if you haven't been doing it for 30 years. :-)

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



On October 8, 2016 6:48:08 PM Monte Goulding <[hidden email]> wrote:

> 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



_______________________________________________
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 4:21 PM, J. Landman Gay <[hidden email]> wrote:
>
> It's only non-obvious if you haven't been doing it for 30 years. :-)


That’s not selling it to me ;-)

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 Monte Goulding-2
At 11:23 AM +1100 10/9/2016, Monte Goulding wrote:

>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.

Hmm. I actually would have expected stack C to still be the
defaultStack on returning to stack A. defaultStack is a global
property, theoretically.


>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.

Not sure how that makes it impossible to set it to the topStack...?

(Although I agree with Jacque that there's code out there that relies
on the current behavior, possibly without the writer even really
being aware of it.)

_______________________________________________
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:10 PM, Jeanne A. E. DeVoto <[hidden email]> wrote:
>
> At 11:23 AM +1100 10/9/2016, Monte Goulding wrote:
>> 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.
>
> Hmm. I actually would have expected stack C to still be the defaultStack on returning to stack A. defaultStack is a global property, theoretically.

What if stack C is only opened sometimes or stack A doesn’t even know about it. Considering this seriously impacts the function of the remaining stack A script I suspect if you think on it some more you want to be more sure about what will mess with it and how it will mess with it than you are suggesting. Anyway, it’s one of those things that would be near on impossible to change if anyone wanted to so there’s no huge point going down that path.

BTW I think defaultStack shouldn’t really be considered a global property. It behaves much more like a local property most of the time. The only times it behaves like a global property are when application level messages are sent to the defaultStack (suspend, resume, shutdown etc) but as there’s no real guarantee which stack that happens to be at the time the event comes it means most of those events messages end up being handled by libraries to make sure we get them. Those messages probably would have been better sent directly to the application mainstack (or home in the IDE) but that ship has sailed too.

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'

Paul Dupuis
There is an even worse issue that has cropped up regarding "the
defaultstack" in a multi-window application

If you have a script executing and present a open file/save file dialog
(which are now non-modal windows under OSX and Windows), the user can
click on other application windows, which cause the clicked-on window to
be "topLevel" and hence the new defaultStack and then click backc to the
open file "dialog" (which are not real dialogs any more) and respond.
Your paused script continues executing, but now the defaultStack has
changed.

As a precaution against users of the app doing (resonable) things like
this, I now explicitly set the defaultStack after any ask or answer file
dialog. I also use code such as

on handler
put the defaultStack into tPreserveDefaultStack
set the defaultStack to <this stack by name>

... my code...

set the defaultStack to tPreserveDefaultStack
end handler

So that if the hander is called from another stack it does not exit with
the defaultstack changed.

_______________________________________________
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
At 8:40 AM -0400 10/9/2016, Paul Dupuis wrote:

>Your paused script continues executing, but now the defaultStack has
>changed.
>
>As a precaution against users of the app doing (resonable) things like
>this, I now explicitly set the defaultStack after any ask or answer file
>dialog. I also use code such as
>
>on handler
>put the defaultStack into tPreserveDefaultStack
>set the defaultStack to <this stack by name>
>... my code...
>set the defaultStack to tPreserveDefaultStack
>end handler
>
>So that if the hander is called from another stack it does not exit with
>the defaultstack changed.


At this point, I'm starting to wonder whether the defaultStack should
be redesigned/re-specced to make it more predictable.

I don't think it's feasible to actually make major changes in the way
the defaultStack works, but possibly a new property could be designed
that acts in such a way that workarounds like this aren't normally
needed. Setting and re-setting the defaultStack to make sure it's
right is almost as annoying as specifying the stack every time you
refer to an object (which I sometimes do anyway, for fear of the
defaultStack changing from under me).

If it were being designed from scratch, what would the ideal behavior
be for a targetStack property? Should it remain unchanged while a
script is running (unless set explicitly)?

_______________________________________________
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/9/16 3:25 PM, Jeanne A. E. DeVoto wrote:

> I don't think it's feasible to actually make major changes in the way
> the defaultStack works, but possibly a new property could be designed
> that acts in such a way that workarounds like this aren't normally
> needed. Setting and re-setting the defaultStack to make sure it's right
> is almost as annoying as specifying the stack every time you refer to an
> object (which I sometimes do anyway, for fear of the defaultStack
> changing from under me).
>
> If it were being designed from scratch, what would the ideal behavior be
> for a targetStack property? Should it remain unchanged while a script is
> running (unless set explicitly)?

What about a "lock defaultstack" command?

--
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'

Paul Dupuis
In reply to this post by Jeanne A. E. DeVoto
On 10/9/2016 4:25 PM, Jeanne A. E. DeVoto wrote:
> If it were being designed from scratch, what would the ideal behavior
> be for a targetStack property? Should it remain unchanged while a
> script is running (unless set explicitly)?

Some long time ago, someone on this list suggested a control block such
as "using <objectReference>" ... "end using"

Where any object references in the block would always be evaluated
relative to the object referred to in the start of the using block.
So:

using card 3 of stack "X"
  put the label of btn "A" into myVar
  ...
end using

Would look for button "A" on card 3 of stack "X"

using stack "X" would be essentially the same as set the defaultStack to "X"

but you could also do things like

using grp id 1005 of card 3 of stack "X"
   repeat with i=1 to the number of fields
     -- would refer only to the field in group ID 1005 of card 3 of
stack "X"
   end repeat
end using

nested using block would presumably be possible

I always though this enhancement would be a great addition to LiveCode.
I would suggest this as a compliment to the defaultStack.

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

Dave Kilroy
In reply to this post by Graham Samuel-4
+1 on a ‘using … end using’ block - it would be so useful!


On 10/9/2016 9:35 PM, Paul Dupuis wrote:

> Some long time ago, someone on this list suggested a control block such
> as "using <objectReference>" ... "end using"
>
> Where any object references in the block would always be evaluated
> relative to the object referred to in the start of the using block.
> So:
>
> using card 3 of stack "X"
>   put the label of btn "A" into myVar
>   ...
> end using
>
> Would look for button "A" on card 3 of stack "X"
>
> using stack "X" would be essentially the same as set the defaultStack to "X"
>
> but you could also do things like
>
> using grp id 1005 of card 3 of stack "X"
>    repeat with i=1 to the number of fields
>      -- would refer only to the field in group ID 1005 of card 3 of
> stack "X"
>    end repeat
> end using
>
> nested using block would presumably be possible
>
> I always though this enhancement would be a great addition to LiveCode.
> I would suggest this as a compliment to the defaultStack.
_______________________________________________
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
"The first 90% of the task takes 90% of the time, and the last 10% takes the other 90% of the time."
Peter M. Brigham
Reply | Threaded
Open this post in threaded view
|

Re: Understanding 'the defaultStack'

Trevor DeVore
On Sun, Oct 9, 2016 at 3:52 PM, Dave Kilroy <[hidden email]>
wrote:

>
> On 10/9/2016 9:35 PM, Paul Dupuis wrote:
> > Some long time ago, someone on this list suggested a control block such
> > as "using <objectReference>" ... "end using"
> >
> > Where any object references in the block would always be evaluated
> > relative to the object referred to in the start of the using block.
> > So:
> >
> > using card 3 of stack "X"
> >   put the label of btn "A" into myVar
> >   ...
> > end using
>

I like the idea of a block like this.

Really I want all code in my UI stacks to ALWAYS use the stack they are
attached to as the default stack in cases where a stack isn't provided in
the object reference. I too have seen "can't find object" errors occur in
code that executes in my UI after displaying a modal dialog to the user.

--
Trevor DeVore
ScreenSteps
www.screensteps.com    -    www.clarify-it.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'

Jeanne A. E. DeVoto
In reply to this post by Paul Dupuis
At 4:42 PM -0400 10/9/2016, Paul Dupuis wrote:

>Some long time ago, someone on this list suggested a control block such
>as "using <objectReference>" ... "end using"
>
>Where any object references in the block would always be evaluated
>relative to the object referred to in the start of the using block.
>So:
>
>using card 3 of stack "X"
>   put the label of btn "A" into myVar
>   ...
>end using
>
>Would look for button "A" on card 3 of stack "X"


How should this work for subroutines? Should the "using" scope also
propagate to any handlers called from within the block?

   on mouseUp
     using stack "My Stack"
       answer field 1 of card 2 -- of stack "My Stack"
       doSomethingElse
     end using
   end mouseUp

   -- maybe in another object's script:
   on doSomethingElse
      answer field 2 of card 2 -- of My Stack? Or the current defaultStack?
   end doSomethingElse


I'm inclined to think that anything that's called from within a
"using" block should use that scope in turn.

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

Mark Waddingham-2
In reply to this post by J. Landman Gay
On 2016-10-09 07:19, J. Landman Gay wrote:
> 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.

Rather than a bug or an anomaly it *could* be considered part of the
semantics of the 'go' command (whether it *should* or not, is another
matter ;))... Which has different behavior from 'toplevel', 'modeless'
etc. commands. If you do:

   toplevel stack "Foo"

Then the defaultStack *does not change*. If you do:

   go stack "Foo"

Then the defaultStack *does change*.

> 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 suspect that the behavior of the defaultStack could be refined to be
more 'predictable' without breaking too much - as you say, I doubt the
semantics of 'go' could be changed. However, all that means is that we
need to make sure there is a way to open secondary stacks without the
defaultStack changing semantics. I *think* the current 'subwindow'
commands (mentioned above) are probably it - but there is still
potential for refinement.

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

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

Mark Waddingham-2
In reply to this post by Jeanne A. E. DeVoto
On 2016-10-09 22:25, Jeanne A. E. DeVoto wrote:

> At this point, I'm starting to wonder whether the defaultStack should
> be redesigned/re-specced to make it more predictable.
>
> I don't think it's feasible to actually make major changes in the way
> the defaultStack works, but possibly a new property could be designed
> that acts in such a way that workarounds like this aren't normally
> needed. Setting and re-setting the defaultStack to make sure it's
> right is almost as annoying as specifying the stack every time you
> refer to an object (which I sometimes do anyway, for fear of the
> defaultStack changing from under me).
>
> If it were being designed from scratch, what would the ideal behavior
> be for a targetStack property? Should it remain unchanged while a
> script is running (unless set explicitly)?

I don't think its even possible to add a new property which works
'better' (by some metric) as the defaultStack is what is used to 'fill
in' missing stack references in chunk expressions - thus its
defaultStack, or something else, but not both (otherwise there's no way
for the engine to know whether you want to use the new fangled
targetStack for that purpose, or the old fashioned defaultStack for that
purpose - in any one case).

I wonder if there are just some cases in the current behavior which need
some review and refinement - in particular, the scope of the changes to
the defaultStack.

One thing to consider is what the locality of a change should be. In
particular:

   1) If the defaultStack is changed in a handler, should it remain that
way for all subsequent commands (which don't explicitly change the
defaultStack) and should the change recurse into called functions and
commands?

   2) If the defaultStack is changed in a handler called from another
handler, should the change propagate back up to the caller?

I think (1) is definitely wanted. If you have changed the defaultStack
in a handler, then it makes sense that anything executed within that
handler, and any handlers invoked within it should use that context.

I think (2) is definitely not wanted. If the locality of a change to the
defaultStack propagates back to callers, then the callers loose control
and knowledge of what they are actually acting on.

If changes propagate down, and not up then all we need to do is mark
commands which explicitly change the defaultStack as doing so. e.g.

   1) go stack tStack - open stack tStack and set the defaultStack to it

   2) set the defaultStack to tStack - set the defaultStack to tStack

   3) send tMessage to tObject - execute tMessage in the context of
tObject, setting the defaultStack to the stack of tObject for the
duration of the handler

   4) call tMessage to tObject - execute tMessage of tObject, leaving the
defaultStack untouched

With that in mind then the proposed 'using' clause would basically just
be a local push / pop of the defaultStack:

   using stack "foo"
     ...
   end using

Would be equivalent to:

   put the defaultStack into tOldDS
   set the defaultStack to "foo"
   ...
   set the defaultStack to tOldDS

Anyway, the above is just a suggestion (on the whole) - I'm not sure the
above to rules (i.e. defaultStack changes propagate into callees, not
back into callers) necessarily model the current usage that well or not.
However, they are (at least) relatively easy to write down and
understand (?).

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps


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

Mark Waddingham-2
On 2016-10-11 11:01, Mark Waddingham wrote:
>   2) If the defaultStack is changed in a handler called from another
> handler, should the change propagate back up to the caller?
>
> I think (2) is definitely not wanted. If the locality of a change to
> the defaultStack propagates back to callers, then the callers loose
> control and knowledge of what they are actually acting on.

Note that this is *not* the current behavior. Changing the defaultStack
in a callee will propagate the change back up to the caller.

i.e.

on mouseUp
   set the defaultStack to "Foo"
   changeDefaultStackInCallee
   answer the defaultStack -- will be "Bar"
end mouseUp

on changeDefaultStackInCallee
   set the defaultStack to "Bar"
end changeDefaultStackInCallee

Here you'll get 'Bar' in the answer dialog.

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

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

Bob Sneidar-2
In reply to this post by Richard Gaskin
Wait what? It has to be visible? THAT I did NOT know. So hiding a stack will make it NOT the defaultStack if another visible stack is open.

Bob S


On Oct 8, 2016, at 13:22 , Richard Gaskin <[hidden email]<mailto:[hidden email]>> wrote:

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

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

Bob Sneidar-2
In reply to this post by Richard Gaskin
Seems to me one unexpected outcome would be if you had the command "hide me" early in the script of a stack where another stack was visible, and then made references dependent on the defaultStack being the one hidden.

Bob S


On Oct 8, 2016, at 14:12 , Richard Gaskin <[hidden email]<mailto:[hidden email]>> wrote:

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

_______________________________________________
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
Bob Sneidar wrote:

 > Seems to me one unexpected outcome would be if you had the command
 > "hide me" early in the script of a stack where another stack was
 > visible, and then made references dependent on the defaultStack being
 > the one hidden.

I think maybe one of the reasons we've seen more posts exploring the
definition of defaultStack than we see complaints about its behavior is
that in practice it's rarely needed.

I use topStack often but mostly in dev tools; in my own apps I tend to
use custom functions to distinguish windows by semantic role rather than
behavioral modality.

I can't recall the last time I needed defaultStack.  It may well have
been quite recently, but it must being doing what I expected it to do
since I've never had to think about it before this thread.

--
  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 15 Oct 2016, at 8:01 AM, Richard Gaskin <[hidden email]> wrote:
>
> I can't recall the last time I needed defaultStack.  It may well have been quite recently, but it must being doing what I expected it to do since I've never had to think about it before this thread.

Every time you use an object reference that doesn’t contain an explicit stack reference you are using the defaultStack. You might not be getting or setting the value but you would be depending on it in a large part of your code.

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'

Richard Gaskin
Monte Goulding wrote:

 >> On 15 Oct 2016, at 8:01 AM, Richard Gaskin wrote:
 >>
 >> I can't recall the last time I needed defaultStack.  It may well
 >> have been quite recently, but it must being doing what I expected
 >> it to do since I've never had to think about it before this thread.
 >
 > Every time you use an object reference that doesn’t contain an
 > explicit stack reference you are using the defaultStack. You might
 > not be getting or setting the value but you would be depending on
 > it in a large part of your code.

Exactly.  It must be working pretty well as it is or we would have had
many more confused posts for decades rather than just a dozen only very
recently.

--
  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'

Peter Bogdanoff
In reply to this post by Bob Sneidar-2
Just tested in 8.1.1 RC 2: Two stacks open, one stack is the topStack and is the defaultStack.

Setting that stack’s visible to false keeps it as the defaultStack and the topStack.

Peter Bogdanoff

On Oct 14, 2016, at 1:37 PM, Bob Sneidar <[hidden email]> wrote:

> Wait what? It has to be visible? THAT I did NOT know. So hiding a stack will make it NOT the defaultStack if another visible stack is open.
>
> Bob S
>
>
> On Oct 8, 2016, at 13:22 , Richard Gaskin <[hidden email]<mailto:[hidden email]>> wrote:
>
> The rule Dr. Raney gave me is that the defaultStack is the topmost visible stack of the lowest mode.
>
> _______________________________________________
> 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
123