WorkFolow oddity
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
WorkFolow oddity
This has happened to me now and then forever, and to others as well.
I have a handler that sends a "mouseUp" message to a button. That button has an "ask dialog line in its "mouseUp" script.
If I simply run the handler, all works fine, but with no blinking cursor in the dialog; I have to click manually to continue.
But if I place a breakPoint anywhere in the flow of the button script before the "ask" line, and simply continue from there, the ask dialog always appears with a blinking cursor.
It is a minor inconvenience. but a major mystery for me.
Reproducible, finally, if that matters.
Craig
I have a handler that sends a "mouseUp" message to a button. That button has an "ask dialog line in its "mouseUp" script.
If I simply run the handler, all works fine, but with no blinking cursor in the dialog; I have to click manually to continue.
But if I place a breakPoint anywhere in the flow of the button script before the "ask" line, and simply continue from there, the ask dialog always appears with a blinking cursor.
It is a minor inconvenience. but a major mystery for me.
Reproducible, finally, if that matters.
Craig
-
- VIP Livecode Opensource Backer
- Posts: 7237
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: WorkFolow oddity
My guess: A breakpoint allows the engine to catch up because it breaks the flow of messages and effectively creates an idle period. Try adding a "wait 0 with messages" and see if that gives LC a chance to do its default behavior.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: WorkFolow oddity
Jacque.
I think you recommended something like that, to me, a long time ago. But I do this in other places and the blinking cursor appears just fine. But I will try it anyway on Monday.
Craig
I think you recommended something like that, to me, a long time ago. But I do this in other places and the blinking cursor appears just fine. But I will try it anyway on Monday.
Craig
-
- VIP Livecode Opensource Backer
- Posts: 9840
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: WorkFolow oddity
Does the issue occur if you click the button containing the mouseup handler directly, or only when using "send" to that?
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: WorkFolow oddity
Richard.
Clicking the button with the "ask" command always works fine, as it should. I just whipped up a simple stack with a button that sends"mouseUp" to another button with an "ask" command. The blinking cursor appears normally.
I have a sneaking feeling that Jacque's suggestion will fix it in my project at work. I just do not know why.
Craig
Clicking the button with the "ask" command always works fine, as it should. I just whipped up a simple stack with a button that sends"mouseUp" to another button with an "ask" command. The blinking cursor appears normally.
I have a sneaking feeling that Jacque's suggestion will fix it in my project at work. I just do not know why.
Craig
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: WorkFolow oddity
Jacque wrote:
works fine from the msg box, but not at all as the last line of a handler.
To recap, I can click on the field, and a normal dialog appears with a blinking cursor. I can set a breakpoint in either the calling handler or the field script, and the dialog appears normally, after I manually continue program flow. But if I let the process run by itself, no cursor ever appears.
If I make a brand new stack, the process works just fine. So there is something in my real stack that prevents it.
Craig
It does not. Again, this:My guess: A breakpoint allows the engine to catch up because it breaks the flow of messages and effectively creates an idle period. Try adding a "wait 0 with messages" and see if that gives LC a chance to do its default behavior.
Code: Select all
click at the loc of fld "myField"
To recap, I can click on the field, and a normal dialog appears with a blinking cursor. I can set a breakpoint in either the calling handler or the field script, and the dialog appears normally, after I manually continue program flow. But if I let the process run by itself, no cursor ever appears.
If I make a brand new stack, the process works just fine. So there is something in my real stack that prevents it.
Craig
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: WorkFolow oddity
Well, if I lock messages, and DO NOT unlock them, the blinking cursor works just fine. Why this should be so is a mystery to me.
Craig
Craig
-
- VIP Livecode Opensource Backer
- Posts: 7237
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: WorkFolow oddity
That implies there's something in the scripts that's removing the cursor or resetting the focus. I had to solve a similar issue yesterday where a list field did not retain its hilitedline. It took me an hour to track it down.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com