| Author |
 Topic  |
|
|
Hard.Wired
84 Posts |
 Posted - 09/30/2019 : 02:35:55
|
Anyone else having odd problems with Windows 10 (1903) and the Edge browser?
I finally had to succumb to the 1903 upgrade and noticed that some of my S+ acSendKeys commands no longer function reliably. In particular things like "^w", "%{LEFT}" and "%{RIGHT}". They still work correctly in other browsers (Chrome, Firefox, Brave).
Things that make you go... Hmmm. |
|
|
Rob
USA
2615 Posts |
Posted - 09/30/2019 : 09:43:32
|
I don't run the original version anymore obviously, but there is a similar issue in S+.net with the Always Activate Window Where Gesture Began option; if it's enabled the same behavior occurs.
There's something very odd about Edge's window hierarchy. So if you have code (like in before action script) which is trying to activate the Edge window first, that might be the source of the issue...but I cannot say for sure. |
 |
|
|
Hard.Wired
84 Posts |
Posted - 09/30/2019 : 14:53:15
|
Bingo...ish. I was using "Allow After Action Script*", "Allow X1 Click Script*" and "Allow X2 Click Script*", but deactivating X1/X2 finally got things working again. I can live without those for the moment. "After" still seems to work.
Thanks!
|
|
|
|
Hard.Wired
84 Posts |
Posted - 09/30/2019 : 15:58:12
|
| Drat, spoke too soon. It worked temporarily. Hmm, I'll look into how I am activating the window. Maybe I can find a work around. |
|
|
|
Hard.Wired
84 Posts |
Posted - 10/01/2019 : 01:21:49
|
Something I just noticed:
Doesn't work...
acSendKeys("^w")
Does work...
acSendControlDown()
acSendKeys("w")
acSendControlUp()
I looked more into Edge's window hierarchy as you mentioned. It was strange before where there would be odd delays when activating the window if it wasn't already in focus, but now it is really weird in 1903 where the order of the hierarchy seems random. I'm sure there is some logic to it (or at least I hope). I'll keep digging.
|
|
|
|
Rob
USA
2615 Posts |
Posted - 10/01/2019 : 09:45:25
|
So what I've found in trying to resolve for S+.net is that when you activate the top level window (ApplicationFrameWindow), it changes the focus to the main body/browser area window of Edge (Windows.UI.Core.CoreWindow). It's during this switch when keyboard input is sent to the top level window (and basically lost), once CoreWindow is active, the input is received fine.
That explains why you send control down works because it sets the keystate globally and buys a little time for CoreWindow to become active. Adding a small delay also seems to work (in S+.net), like acDelay(100) before sending keystrokes to allow CoreWindow to be reactivated and ready to receive input. |
|
|
|
Rob
USA
2615 Posts |
Posted - 10/01/2019 : 09:49:26
|
| Note that it's not all Core apps. For example, Calculator has no problem with this even though its hierarchy is basically the same. It's something specific in the Edge architecture/messaging. |
|
|
|
Hard.Wired
84 Posts |
Posted - 10/01/2019 : 17:50:12
|
| Thank you, very helpful info. I wonder if it also has something to do with Edge's sandboxing methods? This all may change once the new Edge/Chromium version is officially released. PITA! |
|
|
| |
Topic |
|
Windows 10 (1903) / Edge browser / acSendKeys
Forum Locked
