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 ho
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 n
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
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
> 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 l
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 variabl
ackConstants [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
&
iables, 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
_
openStack handler is run.
END COMMENT
He has kindly corrected the title of my bug report -
http://quality.runrev.com/show_bug.cgi?id=11832
Now I'm going to change the script local variables to constants which Jacque
was kind enough to introduce to me in a previous comment on this threa
I think the idea is to be able to preload a variable the first time a script is
accessed in a session, and by session I mean when the application is launched.
Quitting and re-launching the app would count as a second session. While the
app is running, you could change the variable and it’s value
mouseUp
>
> I click button A and "xyz" appears in the message box.
>
> I click button B, then button A and "abc" appears in the message box. So
> you can change the value of script local variables with values assigned in
> this way.
>
> Here's the
isn't what it's about.
Not quite so puzzled
Graham
On 23 Feb 2014, at 20:09, J. Landman Gay wrote:
> On 2/23/14, 12:17 PM, Bob Sneidar wrote:
>> Could it be that editing the script resets the script local
>> variables? This is true in Applescript properties. Edi
Right, otherwise CONSTANT would just be another name for VARIABLE.
Bob
On Feb 23, 2014, at 11:14 , J. Landman Gay wrote:
> On 2/23/14, 4:30 AM, Graham Samuel wrote:
>> I've just read that bit of the dictionary and I'm equally surprised.
>> I also think I must have completely misunderstood it
useUp
In button B on the card, I have
on mouseUp
changeVar
end mouseUp
I click button A and "xyz" appears in the message box.
I click button B, then button A and "abc" appears in the message box. So
you can change the value of script local variables with values assigned
On Sun, Feb 23, 2014 at 11:14 AM, J. Landman Gay
wrote:
> I haven't tried it yet, maybe someone else can confirm.
Yes, you can change the value of a script local variable in the way you
described
What's really interesting though is that the value of a script local
variable assigned in this way
On Sun, Feb 23, 2014 at 11:09 AM, J. Landman Gay
wrote:
> Don't think so, that was one of my first tests when I tried to reproduce
> the problem. I'm going with "script error" as the culprit for now.
I confirm that a script compile error wipes out the contents of any
On 2/23/14, 4:30 AM, Graham Samuel wrote:
I've just read that bit of the dictionary and I'm equally surprised.
I also think I must have completely misunderstood it, because I
can't see how it can work. The value of a script local variable
(unless it's predefined using an '=' construction) is und
On 2/23/14, 12:17 PM, Bob Sneidar wrote:
Could it be that editing the script resets the script local
variables? This is true in Applescript properties. Editing and saving
the script resets the properties to their defaults.
Don't think so, that was one of my first tests when I tri
Could it be that editing the script resets the script local variables? This is
true in Applescript properties. Editing and saving the script resets the
properties to their defaults.
Bob
On Feb 22, 2014, at 10:56 , J. Landman Gay wrote:
> On 2/22/14, 12:17 PM, Peter Haworth wrote:
&
Jacque-
Saturday, February 22, 2014, 6:58:35 PM, you wrote:
> They must have changed it when you and I weren't looking. Variable
> assignments are even listed in the examples in the dictionary entry for
> "local". I may have to read the whole dictionary again to see what else
> I've missed.
OK -
I've just read that bit of the dictionary and I'm equally surprised. I also
think I must have completely misunderstood it, because I can't see how it can
work. The value of a script local variable (unless it's predefined using an '='
construction) is undefined until a script is run, and is then
On 2/22/14, 8:42 PM, Mark Wieder wrote:
Scott-
Saturday, February 22, 2014, 6:26:31 PM, you wrote:
Uh, oh -- I do this all the time.
Is this really not supposed to work?
It sometimes works, but it's not legal syntax.
I don't know of any particular reason why not, but it's not.
They mus
I take it back. The dictionary says you can do it. Whaddya know.
On 2/22/14, 8:26 PM, Scott Rossi wrote:
Uh, oh -- I do this all the time.
Is this really not supposed to work?
Regards,
Scott Rossi
Creative Director
Tactile Media, UX/UI Design
On 2/22/14 6:04 PM, "J. Landman Gay" wrote:
Well, I didn't *think* it was allowed. I confess I never used script
locals that way. If I need to assign a permanent value, I use a constant:
constant kVar = 1234
If the IDE accomodates script locals with assignments, then maybe
something changed. Apparently it doesn't work in standalones.
Scott-
Saturday, February 22, 2014, 6:26:31 PM, you wrote:
> Uh, oh -- I do this all the time.
> Is this really not supposed to work?
It sometimes works, but it's not legal syntax.
I don't know of any particular reason why not, but it's not.
--
-Mark Wieder
ahsoftw...@gmail.com
This communi
Uh, oh -- I do this all the time.
Is this really not supposed to work?
Regards,
Scott Rossi
Creative Director
Tactile Media, UX/UI Design
On 2/22/14 6:04 PM, "J. Landman Gay" wrote:
>>
>>local tMyScriptLocal1
>>local tMyScriptLocal2 = "ghijk"
>>local tMyScriptLocal3
>
>I'm not sure it's a
On 2/22/14, 6:49 PM, Peter W A Wood wrote:
local tMyScriptLocal1
local tMyScriptLocal2 = "ghijk"
local tMyScriptLocal3
I'm not sure it's a fair test. As far as I know, you can't assign a
value to a script local that way, though you can if it's a constant.
Actually, I'm kind of surprised it w
Hi Jacque
On 23 Feb 2014, at 02:56, J. Landman Gay wrote:
> It is, but there's a bug in it somewhere. I use script locals extensively and
> they always worked until somewhere around version 6.x. After that the values
> were occasionally lost. Every subsequent version has made the problem worse,
Hi Jacque,
I've definitely seen values disappear after compiling the script for a long
time but didn't worry abut it too much since that only happens during
development not in production versions.
Like you, I haven't been able to come up with a recipe to reliably
reproduce it.
Pete
lcSQL Softwar
On 2/22/14, 12:17 PM, Peter Haworth wrote:
I think this is dependant on the Variable Preservation setting on the
Preferences Script Editor tab.
It is, but there's a bug in it somewhere. I use script locals
extensively and they always worked until somewhere around version 6.x.
After that the v
I think this is dependant on the Variable Preservation setting on the
Preferences Script Editor tab.
I use script local variables a lot in conjunction with handlers to access
them from other objects instead of custom properties. I started doing it
because custom properties are visible to users
t) for helping me identify and workaround the issues I encountered.
>>>
>>> Paul pointed out three things: I didn't the use "the text of Field ...";
>>> how to overcome not being able to copy text from a field in an OS X
>>> standalone; and the final pro
ot;; how
>> to overcome not being able to copy text from a field in an OS X standalone;
>> and the final problem that was related to script local variables.
>>
>> Using "the text of Field ..." instead of "Field ..." helped to more
>> accurately
2014-02-22 17:04 GMT+01:00 Earthednet-wp :
> Mats' posting on encryption difficulties got me thinking about local
> variables. Are they supposed to persist after the script is done executing,
> so that the next time a handler within that script is called, they can be
> expected to hold previousl
to Roger Eller, Jan Schenkel, Bill Vlahos and Paul Hibbert (off
>> list) for helping me identify and workaround the issues I encountered.
>>
>> Paul pointed out three things: I didn't the use "the text of Field ..."; how
>> to overcome not being able
e issues I encountered.
>
> Paul pointed out three things: I didn't the use "the text of Field ..."; how
> to overcome not being able to copy text from a field in an OS X standalone;
> and the final problem that was related to script local variables.
>
> Using "
41 matches
Mail list logo
