AutoHotkey Community

pseudo-code

I think that's solvable. The problem is that no one wants bothered to do it. Why don't you try to be the first one?

I think you'll find that this works with an independent IE instance. But it won't work with a WebBrowser control that's embedded in an AHK Gui. If you have working code that demonstrates the effective use of {Tab}, {Shift-Tab} and {Enter} within an embedded WebBrowser control, then please post it. It's been requested several times - not just for the IE/COM standard libraries, but also with other ways of wrapping the WebBrowser control into AHK (cwebpage.dll, among others).

Oh yes - I think it's solvable. But handling accelerators properly is never easy (see the sources referenced in my previous post). Since {Tab}, {Shift-Tab} and {Enter} are critical to tab ordering behavior for any AHK Gui that has other controls in addition to the WebBrowser control, the code could get fiendishly complex. (For example, what should happen if you {tab} past the last field in the Webbrowser control? Should it tab into the next control in the AHK Gui? Or should it tab back to the first control in the WebBrowser?). I don't have the necessary COM skills to do this, or the time to code this. Do you? Why don't you try to run Internet Explorer and directly control its window (sizing, navigating, and so on), instead of using an embedded WebBrowser control?

{Enter} may be solved easily using Hotkey. {Tab} part is tricker, however.

Nice workaround! But bear in mind that this will have the effect of disabling normal {Enter} behavior for any other AHK Gui control on your form that can normally "consume" the {Enter} key - the "default" button, for example, or the Text or Edit fields.

which is why you could add a check with MouseGetPos and/or ControlGetFocus to the code to make sure it is only used when the IE control is active.

Sounds like you're familiar with this issue. So... Thanks!

untested

You may use OnMessage instead then.

I added a check for the {Tab} key to your code as well - disheartening results:
Some funky stuff going on in the messages between parent and child windows. Winspector shows a hierarchy of windows in your gui:

AutoHotkeyGui "WebBrowser"
-->Shell Embedding
---->Shell DocObject View
------>Internet Explorer_Server

Once the {Tab} key's pressed in the "Internet Explorer Server" child, its sole effect seems to be to remove focus from this child. Focus moves up the hierarchy to the "Shell Embedding" window.
In another test, I refocused the "Internet Explorer Server" and POST'ed another {Tab} character, but to no effect.

That's normal, default handling of {TAB} of a dialog box, navigating among the controls. You can observe what I mean in the open/save dialog boxes. You must disable or replace the default handling with your custom procedure. It was easy for {ENTER}, but for {TAB} unfortunately not. I'm suspecting it's only possible in AHK by detouring some APIs.

Or use Hotkey or OnMessage() to capture {TAB} key and trigger a custom procedure.

Yes. The WebBrowser control deliberately disables accelerator keys, apparently. They can be re-enabled, apparently - I just found some code at slashbin.org that appears to be promising:If someone could translate this TranslateAccelerator code, then our conquest of this blasted WebBrowser control would be nearly complete!

Ah, that TranslateAccellerator COM stuff looks promising...

Where is a Sean when you need him

_________________
mirror 1 • mirror 2 • mirror 3 • ahk4.me • PM or

I was thinking about lower-level one, however, I think this one will also work.


I used Global here for simplicity, which I think can be easily overcome.