Re: Understanding 'the defaultStack'

[Peter M. Brigham]

> On Oct 15, 2016, at 10:53 AM, Richard Gaskin  
> wrote:
> 
> Bob Sneidar wrote:
> 
> ….
> > I'm not sure who I am anymore...
> 
> Unless you've experienced a problem with it, just keep doing what you're 
> doing….

Be yourself -- everyone else is already taken. -- Oscar Wilde

— Peter

Peter M. Brigham
pmb...@gmail.com



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[J. Landman Gay]

On 10/15/16 9:53 AM, Richard Gaskin wrote:

We have more posts here exploring its definition than about problems
relating to its behavior.


The discussion was very helpful for me, I've never been clear about when 
I need to specifically set the defaultstack, and usually I only figure 
it out when errors happen. Then I'd set it specifically, still never 
understanding why I had to.


I do use the defaultstack whenever I have many actions that need to 
apply to a stack. If I'm only referring to an object once or twice I use 
a long ID or name, but if I need to do lots of stuff it's way easier to 
have a defaultstack.


One good example is the stack-builder tool I wrote for a client, which 
creates and updates stacks. During creation there are hundreds of 
commands to create objects, apply scripts and properties, import images, 
etc. Using long references in every line of that code would be burdensome.


Until now I couldn't understand why "create stack x" required me to set 
the defaultstack to the newly created one. Now I do.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Richard Gaskin]

Bob Sneidar wrote:

>> On Oct 8, 2016, at 13:22 , Richard Gaskin wrote:
>>> The rule Dr. Raney gave me is that the defaultStack is the topmost
>>> visible stack of the lowest mode.
>>
>> On Oct 14, 2016, at 14:21 , Peter Bogdanoff wrote:
>> 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.
>
>
> That breaks Dr. Raney's rule.

It's been nearly two decades since I had that conversation with Dr. 
Raney.  As I noted earlier, and as Jacque and Peter confirm, it's likely 
I was just mistaken - it seems the actual rule is even simpler:


  The defaultStack is the topmost stack with the lowest mode.


> I'm not sure who I am anymore...

Unless you've experienced a problem with it, just keep doing what you're 
doing.  It seems to be working as expected for most people in most 
circumstances.  We have more posts here exploring its definition than 
about problems relating to its behavior.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Bob Sneidar]

That breaks Dr. Raney's rule. I'm not sure who I am anymore...

Bob S


On Oct 14, 2016, at 14:21 , Peter Bogdanoff 
mailto:bogdan...@me.com>> wrote:

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 
mailto:bobsnei...@iotecdigital.com>> 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 
mailto:ambassa...@fourthworld.com>>
 wrote:

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

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Bob Sneidar]

I think the more experienced devs have found ways to work around it. When in 
doubt, they use absolute references and don't depend on the engine to resolve 
relative references for them. I'm not sure if that makes your point or counters 
it. ;-)

Bob S


On Oct 14, 2016, at 14:08 , Richard Gaskin 
mailto:ambassa...@fourthworld.com>> wrote:

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

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Graham Samuel]

Yes, but the way I think of it is if you do a ‘go’ to another stack, then the 
defaultStack changes so that you can make shorter references to objects in what 
is most likely then the current stack of interest. I got in a muddle  because 
that isn’t always true. I suppose I rubbed along for a few years before I got 
hit by that particular gotcha, so in a way Richard you’re right. Good 
documentation is probably all that’s needed, rather than trying to alter the 
engine’s behaviour.

My two Brexit-influenced, over-valued, eurocents.

Graham
> On 14 Oct 2016, at 23:08, Richard Gaskin  wrote:
> 
> 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
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Peter Bogdanoff]

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  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 
> mailto:ambassa...@fourthworld.com>> wrote:
> 
> The rule Dr. Raney gave me is that the defaultStack is the topmost visible 
> stack of the lowest mode.
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Monte Goulding]

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

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Bob Sneidar]

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 
mailto:ambassa...@fourthworld.com>> 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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Bob Sneidar]

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 
mailto:ambassa...@fourthworld.com>> wrote:

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

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Mark Waddingham]

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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Mark Waddingham]

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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Mark Waddingham]

On 2016-10-09 07:19, J. Landman Gay wrote:

On October 8, 2016 7:06:15 PM Monte Goulding  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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Jeanne A. E. DeVoto]

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 " ... "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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Trevor DeVore]

On Sun, Oct 9, 2016 at 3:52 PM, Dave Kilroy 
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 " ... "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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Dave Kilroy]

+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 " ... "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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Paul Dupuis]

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 " ... "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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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 | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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 
... 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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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 

... 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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Monte Goulding]

> On 9 Oct 2016, at 9:10 PM, Jeanne A. E. DeVoto  
> 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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Jeanne A. E. DeVoto]

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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Monte Goulding]

> On 9 Oct 2016, at 4:21 PM, J. Landman Gay  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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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 | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



On October 8, 2016 6:48:08 PM Monte Goulding  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  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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[J. Landman Gay]

On October 8, 2016 7:06:15 PM Monte Goulding  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 | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Monte Goulding]

> On 9 Oct 2016, at 10:51 AM, Jeanne A. E. DeVoto  
> 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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Monte Goulding]

> On 9 Oct 2016, at 10:51 AM, Jeanne A. E. DeVoto  
> 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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Jeanne A. E. DeVoto]

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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Monte Goulding]

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  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
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[J. Landman Gay]

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 | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



On October 8, 2016 6:17:48 PM "Jeanne A. E. DeVoto" 
 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
livec...@jaedworks.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Monte Goulding]

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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Monte Goulding]

> On 9 Oct 2016, at 10:15 AM, Jeanne A. E. DeVoto  
> 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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Jeanne A. E. DeVoto]

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
livec...@jaedworks.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Monte Goulding]

> On 9 Oct 2016, at 9:09 AM, Graham Samuel  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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Graham Samuel]

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  wrote:
> 
> 
>> On 9 Oct 2016, at 7:22 AM, Richard Gaskin  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
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Richard Gaskin]

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
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Peter M. Brigham]

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  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
pmb...@gmail.com


> On Oct 8, 2016, at 4:54 PM, 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...?
> 
> -- 
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[J. Landman Gay]

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 | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Monte Goulding]

> On 9 Oct 2016, at 7:22 AM, Richard Gaskin  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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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  wrote:


FWIW I think Jacque's explanation is the better of the two.
I think maybe LiveCode should ship  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 | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Dr. Hawkins]

On Fri, Oct 7, 2016 at 10:50 PM, Mark Wieder  wrote:

> FWIW I think Jacque's explanation is the better of the two.
> I think maybe LiveCode should ship  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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Understanding 'the defaultStack'

[Mark Wieder]

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  her with every new build 
of the dictionary.


--
 Mark Wieder
 ahsoftw...@gmail.com



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode