Not only that, I think I overthought this. All I really need to do is retrieve
the array and then use the array elements instead of the variables. It all
started when I began using behaviors and discovered that a behavior does not
have access to a scripts own constants. This was a way for me to
You know you are right. I just noticed that. That syntax of mine should not
have even worked LOL! Talk about a forgiving interpreter!
Bob S
> On Jun 26, 2018, at 23:25 , Dick Kriesel via use-livecode
> wrote:
>
>> On Jun 26, 2018, at 1:13 PM, Bob Sneidar via use-livecode
>> wrote:
>> ...
> On Jun 26, 2018, at 1:13 PM, Bob Sneidar via use-livecode
> wrote:
> ...
> do "put " & quote & aStackConstants [tConstant] & quote & " into " &
> tConstant
Hi, Bob. If you wanted simpler code, that could be just
do "put aStackConstants[ tConstant ] into " & tConstant
— Dick
Yes that was my problem. Hovering or viewing the variable in the debugger while
getStackConstants was running would show the script local variable values being
updated, but as soon as the handler exited, they were all empty again, meaning
the handler was not updating the script local variables,
i remember debugging a local script in a datagrid behavior and having to
figure out which index it was working on.new window would work the same
but you'd still need to give yourself that piece of data that will tell you
which one it is.
another thing i keep on forgetting in v9 is when you
Hmmm... something you said set me to thinking. Suppose I already had the
instance of a behavior opened in the script editor with a breakpoint set. I
then execute a handler in another object with the same behavior. Which instance
is the script editor going to show me?? Ideally, it should open a
Yes, well for whatever reason it's working now. I didn't change anything, I
just quit and relaunched. It may be some kind of topstack issue where the
topstack is changing and I don't know it's happening.
Bob S
> On Jun 26, 2018, at 13:44 , Tom Glod via use-livecode
> wrote:
>
> h..
h.. look inside the preferences to the script editor. try to
see if "variable preservation" helps you..i think its an engine property.
On Tue, Jun 26, 2018 at 4:41 PM, Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:
>
>
> > On Jun 26, 2018, at 13:30 , J. Landman
yup a feature that makes lc driven datagrid possible. :) and many other
things.
On Tue, Jun 26, 2018 at 4:30 PM, J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:
> Every instance of a behavior maintains its own separate variable values.
> This is a feature. Globals are
> On Jun 26, 2018, at 13:30 , J. Landman Gay via use-livecode
> wrote:
>
> Every instance of a behavior maintains its own separate variable values. This
> is a feature. Globals are the solution if you want them to share the values.
>
I don't want to share the variables. I want them to be
Every instance of a behavior maintains its own separate variable values.
This is a feature. Globals are the solution if you want them to share
the values.
On 6/26/18 3:19 PM, Bob Sneidar via use-livecode wrote:
Works with globals, but not script locals.
Bob S
On Jun 26, 2018, at 13:13 ,
Works with globals, but not script locals.
Bob S
> On Jun 26, 2018, at 13:13 , Bob Sneidar via use-livecode
> wrote:
>
> Hi all.
>
> I have a behavior script with a handler:
>
> local cTableName, cDGName, cPriKey, cAltTable1
>
> on getStackConstants pParentStack
> -- retrieve stack
Hi all.
I have a behavior script with a handler:
local cTableName, cDGName, cPriKey, cAltTable1
on getStackConstants pParentStack
-- retrieve stack constants from stack property
put the stackConstants of pParentStack into aStackConstants
put the keys of aStackConstants into
13 matches
Mail list logo
