Page 1 of 1

Bug 19023

Posted: Sat Sep 23, 2017 10:50 am
by montymay
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

Re: Bug 19023

Posted: Sat Sep 23, 2017 4:20 pm
by bogs
Well Monty, I can't tell you how to work around it, but maybe bouncing some ideas around helps?

This,
text cannot be typed into any field unless the user first clicks outside the window and then clicks in the intended field.
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 -

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
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.

Re: Bug 19023

Posted: Sun Sep 24, 2017 4:50 pm
by jacque
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.

Re: Bug 19023

Posted: Mon Sep 25, 2017 10:00 pm
by bogs
Certainly sounds easier than my idea, wonder if he ever tried it.

Re: Bug 19023

Posted: Fri Sep 29, 2017 9:32 am
by montymay
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

Re: Bug 19023

Posted: Fri Sep 29, 2017 2:05 pm
by bogs
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:

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
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.

Re: Bug 19023

Posted: Fri Sep 29, 2017 9:52 pm
by jacque
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.
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.

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
You may need to tweak it a little, right now it only resets the focus when the mouse is over the card itself. If there is any control under the mouse then nothing should happen.

No promises, but worth a try.