script scope variables inexplicably becoming unset

[Dr. Hawkins]

On Fri, Jan 2, 2015 at 5:46 PM, Peter Haworth <pete at lcsql.com> wrote:

>
> I confirm that there is a missing behavior but it's on grp "grp_calcids"
>  There's also another one on field "Edit" of group "mcp_menu" on the same
> card.  I suspect as a result of Dr Hawkins stripping down the stack
>
> Yes.  I missed stripping the calcPop group (grp_calcids) because it was
invisible.  There are actually several buttons in that funny-colored group
on mcp.  (and the handlers are far longer)

I left the menus in "just in case"--I haven't touched them in over a year .
. .

I'm baffled by the size of this stack alter all that stripping . . .

>
> Dr Hawkins,
> I just finished taking a look at this stack and found some possible reasons
> for what's happening.
>
> thank you!

> If you keep keying in letters after the d, the palette stack does appear
> and stays as you continue to key in so it's an intermittent problem not
> absolute.
>

it gets the palette message on every textChanged, as it is supposed to go
away if the mouse leaves both it and the related field. Someone could tab
in (no need to pop up) and then start making changes.  As I read the
dictionary, the palette command does nothing if the stack is already open
as a palette.


>
> First the issue of the palette command clearing a local variable.
>
> At line 56+ of field src_fltrpopup, I found:
>
> palette savChStk
>
>       if word 2 of savChStk is not among the words of the openStacks then
>          ck "it's not open!" & cr & "chStk is: " & chStk
>
> The If statement is checking savChStk against the openStacks but your ck
> text references chStk, a completely different variable.


chStk is the "real" variable.  I added savChStk to stash it in when it
started getting whacked.  The code *should* just have chStk.  Using
savChStk was one of the attempts to protect it, but chStk still got
whacked.  So did single and double parenthesis to try to force a copy to be
passed.


> I changed the
> chStk to savChStk  in the ck command and the display now shows that it
> contains the correct value of "stack ctrlChoices" so your palette command
> is not destroying the contents of a variable.  If you meant to check chStk,
> see later in this email.
>

I did mean to check chStk; when this is solved, savChStk is gone entirely.

>
> Next problem - why is the stack not showing up in the openStacks?
>
> I added a put to the message box in the preOpenStack handler of the
> ctrlChoices stack including the milliseconds and I can see that the stack
> is opened every time the src_fltrpopup field is altered in any way, so your
> palette command is working just fine.  Something must be closing it
> immediately it opens in certain circumstances.
>

Wow.  It didn't even occur to me as a way to check.

perhaps putting the same into a closeStack handler with a hard breakpoint
will let me see the context.  Hmm, or my ck that also logs could log the
executionContexts.


> There's a handler named  hideChcStk in the src_fltrKeyField of your mcp
> stack so I added another put to the message box in there and see it closing
> the stack when the ctrlChoices does not appear, but not every time. It also
> puts empty into variable chStk which might also explain the first issue.
>

What is *supposed* to happen is that when either the host field or the
stack gets a mouseLeave, it checks to see if the mouse is within the
other.  If not, ctrlChoices gets closed.

>
> I also see that button is a behavior for the abbrev field where you key in
> "ard" etc.
>

Yes.  In normal operation, those buttons in mcp wouldn't be visible.  (For
that matter, once I write the menus, mcp itself probably won't be visible.
Normally just the upper left corner sows.

>
> There's also a mouseLeave handler in the stack script of ctrlChoices which
> closes the stack in some circumstances.
>
> Don't have time to check further but the stack is being opened when it
> should but being closed immediately in some circumstances.  What those
> circumstances are, I'll leave you to figure out.


Thank you very much.  I had thought I had seen an occasional flicker, but
didn't believe my eyes.

I think I now know what I need to to catch it.

However, this still leaves the problem that it is not single-stepping into
handlers where this behavior happens . . .

-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462