script scope variables inexplicably becoming unset

[Scott Rossi]

I haven't totally followed this discussion but it sounds like you might be relying solely on the debugger to display the values of script variables.  You might try using a more direct approach by using a command or getProp handler to dump variable values into the message box or a field so you can see them. Also consider setting up a timed script to monitor the variable you think is being changed so you can verify where in your sequence of events this might be happening.

Regards,

Scott Rossi
Creative Director
Tactile Media UX/UI Design


> On Dec 31, 2014, at 10:12 AM, Dr. Hawkins <dochawk at gmail.com> wrote:
> 
> On Wed, Dec 31, 2014 at 9:51 AM, J. Landman Gay <jacque at hyperactivesw.com>
> wrote:
> 
>> Again, any time you change stacks the focus will change. When that happens
>> the selection usually gets wiped. Locking messages won't help in this
>> situation; that just means the engine won't send event reports to your
>> scripts but it doesn't change how the engine behaves.
>> 
> 
> The selection isn't an issue anymore; it is no longer used.
> 
> The problem is that the local script-scope variable, which is supposed to
> be persistent short of the recompile of the script, is being emptied by the
> opening of the palette--with both messages locked and the open/preopen
> scripts of the palette stack existing and being empty.
> 
>> 
>> Clicking on something, opening something, etc. usually removes the
>> selection, which should be considered as temporary as "the result" or "it".
>> (List fields are an exception because they store the hilitedline natively.)
>> It will usually still be there if nothing else happens, but in this case
>> you are opening another stack and using an answer dialog, both of which
>> change the focus.
>> 
>> The best approach is to store the selection in a variable before you do
>> anything else, if you are going to need it later.
>> 
> 
> But what I'm losing *is* a variable!  The selection manipulations have been
> completely removed in favor of a handler that does things on textChanged.
> The problem is that opening a stack is resetting a local variable.
> 
> I added another pair of checks here
>   lock messages --chStk becomes unset during openstack!
>      ck  "chStk pre:" &chStk
>      palette (chStk)
>      ck  "chStk post:" &chStk
>      unlock messages
> (and recall that openStack and preOpenStack are empty handlers in stack
> ctrlChoices
> The log window shows,
> chStk pre:stack ctrlChoices
> chStk post:stack ctrlChoices
> chStk pre:stack ctrlChoices
> chStk post:stack ctrlChoices
> chStk pre:stack ctrlChoices
> chStk post:stack ctrlChoices
> chStk pre:stack ctrlChoices
> chStk post:stack ctrlChoices
> chStk pre:stack ctrlChoices
> chStk post:stack ctrlChoices
> chStk pre:stack ctrlChoices
> chStk post:stack ctrlChoices
> chStk pre:stack ctrlChoices
> chStk post:stack ctrlChoices
> chStk pre:stack ctrlChoices
> chStk post:
> 
> So it works sometimes, and other times resets this varirable . .
> 
> Incidental oddities:
> * saving in 5.5 format left the stack I was working on corrupted, with no
> rescue file.
> * 5.5.4 would open the palette *behind* the current stack, but sometimes
> move it to the top when told to open an additioanl time
> * 5.5.4 wouldn't pass mouseEnter to either a stack or its behavior, but
> *would* catch it if the mouse entered a field on the stack.
> 
> -- 
> Dr. Richard E. Hawkins, Esq.
> (702) 508-8462
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode