Re: Behaviors not honoring script local variables??
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 use script locals in both the behavior and the parent script by having the getStackConstants() function in each one. I'd have to replace every instance of a script local with an array reference, but it's probably better in the long run. Bob S > On Jun 27, 2018, at 15:53 , Bob Sneidar via use-livecode > wrote: > > 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: >>> ... >>> 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 ___ 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: Behaviors not honoring script local variables??
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: >> ... >>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 > ___ > 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: Behaviors not honoring script local variables??
> 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 ___ 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: Behaviors not honoring script local variables??
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, but it's own local variables! It was as though the script local variables did not exist yet. But as I mentioned quitting and restarting *seemed* to have sorted things out. Bob S > On Jun 26, 2018, at 15:04 , Tom Glod via use-livecode > wrote: > > another thing i keep on forgetting in v9 is when you hover over variable > names in the debugger it shows you the value that might help these > kinds of problems. > > keep on keepin on Bob ___ 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: Behaviors not honoring 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 hover over variable names in the debugger it shows you the value that might help these kinds of problems. keep on keepin on Bob On Tue, Jun 26, 2018 at 5:22 PM, Bob Sneidar via use-livecode < use-livecode@lists.runrev.com> wrote: > 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 > new script editor window for every instance, otherwise the variable watcher > is going to produce unexpected results. It may also confuse the engine, > which would explain why I was seeing the results I was seeing, especially > if I was terminating execution mid handler for whatever reason. > > Bob S > > > > On Jun 26, 2018, at 13:49 , Bob Sneidar via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > > 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 < > use-livecode@lists.runrev.com> wrote: > >> > >> 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 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 the solution if you want them to share > the > >>> values. > > >>> > >>> I don't want to share the variables. I want them to be local to the > >>> script. The trouble is, they reset as soon as the handler exits. > Inside the > >>> handler, they all seem to be fine! And ONLY the openStack handler > seems to > >>> be having the issue, because any other handler, even preOpenStack will > >>> retain the script local values! GAH! > >>> > >>> Bob S > >>> > >>> > >>> ___ > >>> 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 > > > ___ > 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: Behaviors not honoring script local variables??
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 new script editor window for every instance, otherwise the variable watcher is going to produce unexpected results. It may also confuse the engine, which would explain why I was seeing the results I was seeing, especially if I was terminating execution mid handler for whatever reason. Bob S > On Jun 26, 2018, at 13:49 , Bob Sneidar via use-livecode > wrote: > > 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.. 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 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 the solution if you want them to share the >>> values. >>> >>> I don't want to share the variables. I want them to be local to the >>> script. The trouble is, they reset as soon as the handler exits. Inside the >>> handler, they all seem to be fine! And ONLY the openStack handler seems to >>> be having the issue, because any other handler, even preOpenStack will >>> retain the script local values! GAH! >>> >>> Bob S >>> >>> >>> ___ >>> 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 ___ 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: Behaviors not honoring script local variables??
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.. 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 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 the solution if you want them to share the >> values. >>> >> >> I don't want to share the variables. I want them to be local to the >> script. The trouble is, they reset as soon as the handler exits. Inside the >> handler, they all seem to be fine! And ONLY the openStack handler seems to >> be having the issue, because any other handler, even preOpenStack will >> retain the script local values! GAH! >> >> Bob S >> >> >> ___ >> 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: Behaviors not honoring script local variables??
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 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 the solution if you want them to share the > values. > > > > I don't want to share the variables. I want them to be local to the > script. The trouble is, they reset as soon as the handler exits. Inside the > handler, they all seem to be fine! And ONLY the openStack handler seems to > be having the issue, because any other handler, even preOpenStack will > retain the script local values! GAH! > > Bob S > > > ___ > 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: Behaviors not honoring script local variables??
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 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 , Bob Sneidar via use-livecode < >>> use-livecode@lists.runrev.com> wrote: >>> >>> 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 tConstantList >>> >>>repeat for each line tConstant in tConstantList >>> do "put " & quote & aStackConstants [tConstant] & quote & " into >>> " & tConstant >>>end repeat >>> end getStackConstants >>> >>> When I trace the handler, it does indeed set the values for the local >>> variables, but as soon as the handler exits, the script local variables are >>> all reset! This does not happen when I do the same thing in an object >>> script. Is there something about behaviors preventing script local >>> variables from retaining their values?? >>> >>> Bob S >>> >> >> >> ___ >> 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 >> >> > > -- > 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: Behaviors not honoring script local variables??
> 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 local to the script. The trouble is, they reset as soon as the handler exits. Inside the handler, they all seem to be fine! And ONLY the openStack handler seems to be having the issue, because any other handler, even preOpenStack will retain the script local values! GAH! Bob S ___ 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: Behaviors not honoring script local variables??
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 , 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 constants from stack property put the stackConstants of pParentStack into aStackConstants put the keys of aStackConstants into tConstantList repeat for each line tConstant in tConstantList do "put " & quote & aStackConstants [tConstant] & quote & " into " & tConstant end repeat end getStackConstants When I trace the handler, it does indeed set the values for the local variables, but as soon as the handler exits, the script local variables are all reset! This does not happen when I do the same thing in an object script. Is there something about behaviors preventing script local variables from retaining their values?? Bob S ___ 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 -- 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: Behaviors not honoring script local variables??
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 constants from stack property > put the stackConstants of pParentStack into aStackConstants > put the keys of aStackConstants into tConstantList > > repeat for each line tConstant in tConstantList > do "put " & quote & aStackConstants [tConstant] & quote & " into " & > tConstant > end repeat > end getStackConstants > > When I trace the handler, it does indeed set the values for the local > variables, but as soon as the handler exits, the script local variables are > all reset! This does not happen when I do the same thing in an object script. > Is there something about behaviors preventing script local variables from > retaining their values?? > > Bob S ___ 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
Behaviors not honoring script local variables??
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 tConstantList repeat for each line tConstant in tConstantList do "put " & quote & aStackConstants [tConstant] & quote & " into " & tConstant end repeat end getStackConstants When I trace the handler, it does indeed set the values for the local variables, but as soon as the handler exits, the script local variables are all reset! This does not happen when I do the same thing in an object script. Is there something about behaviors preventing script local variables from retaining their values?? Bob S ___ 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
