Howard:
> All my test show that for the Shift key and the Option key, when
> called within a mousemove handler, it doesn't register that the
> keys are down unless the mouse button is clicked first.
Hi Howard, I tested your code verbatim in the card script of a new stack
in LC 901 on native W
Just a hunch maybe you can quickly toggle visibility of the
widget..after everything is loaded. maybe that will be enough to lose
focus and not have to regain it? unlikely to work, but worth a try.
On Sun, Sep 23, 2018 at 11:15 PM Monte Goulding via use-livecode <
use-livecode@lists.ru
Hi Mike
This is actually a problem for all widgets with native layers. There’s also the
additional complexity with the browser widget that some pages when you open
them they have javascript that focuses in on something.
I have a PR that makes `the focusedObject` and `focus on nothing | object`
Typically I try to avoid Apple latest (beta) upgrade while the early
adopters shake out bugs, usually a series of patches for three months.
But I'm curious, in LiveCode ready for Mohave (released tomorrow)
BR
___
use-livecode mailing list
use-livecode
Correct, but I did have to move the mouse (since it was inside the
mousemove handler). So if I stopped moving and pressed/released the shift,
when I moved the mouse it did change to "down" / "up" as appropriate. It
could be related to the VM. I don't have a Win7 VM, so I can't test that
OS right
already tried focusing on another control, and, I have no idea what
document.activeElement.blur() is supposed to do, but that didn't fix it
either.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe
Thanks Brian,
I don't know what the problem could be. All my test show that for the Shift
key and the Option key, when called within a mousemove handler, it doesn't
register that the keys are down unless the mouse button is clicked first.
I'm running Windows 7 instead of 10, but I doubt that's the
I just did a quick test on Win10 and it works as it should. Tested with LC
9.0.1 stable.
Thanks,
Brian
On Sep 23, 2018, 5:20 PM -0500, Howard Bornstein via use-livecode
, wrote:
> Sadly, both the keysDown() function as well as rawKeyDown, only return a
> keycode for the shift key (and the option
Sadly, both the keysDown() function as well as rawKeyDown, only return a
keycode for the shift key (and the option key) upon key UP. All the other
keys work on key down but these do not. Do you have any idea why?
Should I file a bug report on ShiftKey down? Were you able to verify this
bug from th
Hi ,
Livecode 9.0.1
MacOS High Sierra
Open driver hangs on MacOS , tried Sarah's SerialTest stack which hangs also.
Item 3 of the drivernames is correct but when open driver or file is attempted
it hangs. Bug ?
Regards Camm
___
use-livecode mailing li
Howdy Folks,
I will file a quality report very soon, but wanted to ask what others
are experiencing too.
Using LC 9.0.0 and 9.0.1, on a Windows "PC" laptop with Core i3 or Core
i5, the script editor is painfully slow unless many of the auto
formatting and coloring features are turned off.
> Mike K. wrote:
> How do we take focus away from the browser widget?
Did you already try
do "document.activeElement.blur()" in widget "browser" ?
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscri
might be dumbbut what if istead of focus on nothing you focused on
another control that passes the rawkey?
On Sun, Sep 23, 2018 at 9:15 AM Mike Kerner via use-livecode <
use-livecode@lists.runrev.com> wrote:
> One additional note, Panos suggested that browserDocumentLoadFailed might
> be firi
On 9/22/18 11:03 PM, Howard Bornstein via use-livecode wrote:
This is exceedingly weird. I can't get a mousemove handler to recognize if
the shiftkey is down (although I think this is true for all key
modifiers—Shiftkey down and OptionKey down for sure). The only way it
detects this state is if I
One additional note, Panos suggested that browserDocumentLoadFailed might
be firing.
Surprise it is, but the error is
"plug-in handled load"
but firing a "focus on nothing" inside that event doesn't help, either.
On Sun, Sep 23, 2018 at 7:31 AM Mike Kerner
wrote:
> How do we take focus away fro
How do we take focus away from the browser widget?
I am loading PDF's into the browser widget. At that point, all key presses
get eaten up by the widget (e.g. arrows make the widget scroll), even if a
field has the insertion point.
Scripting the widget to intercept those events doesn't work.
"foc
16 matches
Mail list logo