> 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.
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
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
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 t
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
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 y
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 NO
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 t
> 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 refer
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 po
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...@fourthwor
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 top
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
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 co
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
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 car
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 th
+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
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 blo
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 defaultS
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 suc
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
> 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
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 sta
> 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 u
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 default
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 s
> 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
> 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
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 u
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
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
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)
> 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-liveco
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
> 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 bi
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
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 t
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
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 mod
> 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
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 gav
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
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 revBui
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 t
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:
>
46 matches
Mail list logo
