Bug 19023
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller
Bug 19023
This is not a new topic. I opened it in the following thread.
viewtopic.php?f=7&t=27258
The problem: if in my application you open a card with both fields and a browser widget that programmatically displays a locally stored PDF within it, text cannot be typed into any field unless the user first clicks outside the window and then clicks in the intended field. The presence of the browser appears to be the the cause. This behavior occurs in both the IDE and in standalones, at least on the Windows platform, both 7 and 10. One contributor in the above thread noted it was probably a reported bug:
http://quality.livecode.com/show_bug.cgi?id=19023
I noted my interest in fixing the bug with the LiveCode Quality Control Center on July 26, 2017. The LC analyst (Panos Merakos) noted the behavior depends upon the URL in his testing, but he tested websites whereas the principal use of the browser in my application is the display of locally stored PDFs and the browser always takes focus away from the fields of the card. I have received no information or noted any activity on that page.
So, I write for any suggestions about what to do. An application that I have been working on for several years is useless unless this problem is fixed. How do I get LC to fix the bug? Is there a workaround to fix the behavior? Is there the possibility that this bug is not the cause of this behavior? is there anyone else who replicates my scenario but who does not produce this behavior?
Thanks for any suggestions.
Monty
viewtopic.php?f=7&t=27258
The problem: if in my application you open a card with both fields and a browser widget that programmatically displays a locally stored PDF within it, text cannot be typed into any field unless the user first clicks outside the window and then clicks in the intended field. The presence of the browser appears to be the the cause. This behavior occurs in both the IDE and in standalones, at least on the Windows platform, both 7 and 10. One contributor in the above thread noted it was probably a reported bug:
http://quality.livecode.com/show_bug.cgi?id=19023
I noted my interest in fixing the bug with the LiveCode Quality Control Center on July 26, 2017. The LC analyst (Panos Merakos) noted the behavior depends upon the URL in his testing, but he tested websites whereas the principal use of the browser in my application is the display of locally stored PDFs and the browser always takes focus away from the fields of the card. I have received no information or noted any activity on that page.
So, I write for any suggestions about what to do. An application that I have been working on for several years is useless unless this problem is fixed. How do I get LC to fix the bug? Is there a workaround to fix the behavior? Is there the possibility that this bug is not the cause of this behavior? is there anyone else who replicates my scenario but who does not produce this behavior?
Thanks for any suggestions.
Monty
Re: Bug 19023
Well Monty, I can't tell you how to work around it, but maybe bouncing some ideas around helps?
This,
You can actually pre-test to see if it works without coding anything simply by creating a new stack from the ide, run your program in the ide, and click on the dummy new stack then see if the field accepts the click in the field (I think).
To the user, this should not look like anything at all is happening, and it gives you a way to have the card loose focus and get it back that is totally under your control.
This,
should be able to be simulated through code, couldn't it? If truly a click outside the window containing the field and then clicking on the field allows the action you want, couldn't you do something like this -text cannot be typed into any field unless the user first clicks outside the window and then clicks in the intended field.
Code: Select all
1. create a dummy stack, the only purpose it serves is giving you a target
2. pop it up behind the working stack when calling the card your having the field issue with
3. wherever your handling the action for the field...
...on (event that tells you the pdf is loaded), temporarily lock the screen, select the dummy card, switch back to the working card, focus on the field, unlock the screen
To the user, this should not look like anything at all is happening, and it gives you a way to have the card loose focus and get it back that is totally under your control.
-
- VIP Livecode Opensource Backer
- Posts: 7258
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: Bug 19023
Have you tried "focus on nothing"? When you issue the command would depend on how the app works, but a severe implementation would be to track mouseMove and change the focus if the mouse isn't over the browser or a field.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
Re: Bug 19023
Certainly sounds easier than my idea, wonder if he ever tried it.
Re: Bug 19023
Thanks for the last suggestion. I have not tried "focus on nothing," and would like to try it, but being a newbie, I would like (need!) a little more explanation of what was meant by tracking mouse movement and changing focus when the mouse is not over a field or the browser. I implemented the technique of clicking on a dummy stack and am glad to report that it works, but the former suggestion sounds more elegant. Thanks for any further explanation.
Monty
Monty
Re: Bug 19023
Well, I'm glad to hear my suggestion *did* work, but I agree that was not nearly as nice as Jacque's suggestion.
There are a lot of ways to track the mouses movement and actions built into Lc, such as (dictionary) mouseEnter, mouseLeave, mouseMove, mouseLoc, etc etc. and I am sure you are aware of mouseUp and mouseDown, but here are examples of other mouse messages you can handle:
You can practice like I sometimes do, type 'mouse' into the dictionary and take anything that looks interesting. I usually wrap them in little demo programs, so I can see how it works before applying it to production stuff.
There are a lot of ways to track the mouses movement and actions built into Lc, such as (dictionary) mouseEnter, mouseLeave, mouseMove, mouseLoc, etc etc. and I am sure you are aware of mouseUp and mouseDown, but here are examples of other mouse messages you can handle:
Code: Select all
on mouseDown
set backgroundColor of me to "purple"
end mouseDown
on mouseEnter
set the backgroundColor of me to "red"
end mouseEnter
on mouseWithin
set the backgroundColor of me to "red"
end mouseWithin
on mouseLeave
set the backgroundColor of me to "light blue"
end mouseLeave
-
- VIP Livecode Opensource Backer
- Posts: 7258
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: Bug 19023
Every time the mouse moves, LC sends a "mouseMove" message to the current card, along with the current mouse coordinates. It happens many times per second repeatedly. You can catch that message and do something with it.montymay wrote:Thanks for the last suggestion. I have not tried "focus on nothing," and would like to try it, but being a newbie, I would like (need!) a little more explanation of what was meant by tracking mouse movement and changing focus when the mouse is not over a field or the browser. I implemented the technique of clicking on a dummy stack and am glad to report that it works, but the former suggestion sounds more elegant. Thanks for any further explanation.
This is untested because I can't seem to find the magic URL that will let me display a PDF. But here is the idea:
Code: Select all
on mousemove pX,pY -- not using the coords here, but you can if you need to
if the mousecontrol is empty then
focus on nothing
end if
end mousemove
No promises, but worth a try.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com