On Fri, Jan 2, 2015 at 5:46 PM, Peter Haworth <[email protected]> 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 _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
