|
|
Rank: Advanced Member
Groups: Member
Joined: 10/24/2018
Posts: 97
|
We are currently trialling your EO.WebBrowser product for use in our WinForms application.
However we found that if we are inside an input field in the browser, then opening menus (for example via Alt+keycode) does not work as expected, you for example cannot use the arrow keys to walk through the menus.
I have reproduced this in a test program, it is really simple, the structure is as follows:
We have 1 Form, which has a MenuStrip and a WebControl. The MenuStrip has two ToolStripMenuItems which each have the Shortcutkeys set and two more ToolStripMenuItems as children. In this case we have the File and View menu at top level, with as shortcuts Alt+F and Alt+V respectively. The WebControl has its WebView property set.
What I expect: Pressing Alt+F opens the File menu, it is by default focused on the Open child, and I can use the arrow key to navigate down to the Quit child.
What happens: Pressing ALT+F opens the File menu, it focuses the Open child, but the arrow keys do not show any interaction, in fact I can only reach the Quit child by using my mouse.
When we add an additional control (like an input field) on the Form, then our menu works as expected, it only occurs when the focus is inside the webbrowser's input field.
How to resolve this? This is blocking our successful evaluation of your product.
Update: By pure luck I discovered that holding down Alt makes it work halfway as expected, at that point arrow navigation will work, however there is still no way to actually activate your menu item. Pressing Enter doesn't work and only gives a sound indicating that it (Windows) could not perform an action. Next to that we do not want to have to hold Alt down, we want it to work exactly as any other WinForms control.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,080
|
Hi,
This is just to let you know that we are able to reproduce the issue is currently working to find a solution. We will reply here again when we have an update.
Thanks!
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,080
|
Hi,
We have posted a test build that should resolve this issue. You can see your private message for the download location. Please take a look and let us know whether it resolves the issue for you.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 10/24/2018
Posts: 97
|
Thank you! This seems to be an improvement, but still hasn't fully solved the issue I am experiencing, perhaps I was not clear enough in what I exactly expect.
I have compared this new build with the old situation I have and I notice the following.
In my old (and seemingly correct) situation the following happens.
When pressing/holding Alt without other keys:
1. The mnemonics become highlighted on press.
2. When releasing the first item in the menu strip becomes activate.
When typing Alt + mnemonic while holding alt the correct menu item will open, this works correctly in the new build.
When typing Alt + a number it will generate the special character and put it into the input field and leave the menu strip alone, this also works correctly in the new build.
So it seems to be that only holding/typing Alt is a special case that will need to be treated accordingly.
|
|
Rank: Advanced Member
Groups: Member
Joined: 12/10/2014
Posts: 133
|
Hello there,
I'm also interested in this test build.
I was going to implement it myself but if you guys are working on it ... :)
Looking forward to this futur update.
Regards
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,080
|
Hi,
We have posted build 18.3.46 and it should fix the alt key issue as well. Please download it from our download page and let us know how it goes.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 10/24/2018
Posts: 97
|
Good morning,
Thank you for the new build! The Alt issue seems to be fixed indeed!
However I notice a few new issues when having the focus in an input field on a website:
1. When pressing Alt + Mnemonic the mnemonic key also gets entered in the input field.
2. When pressing Alt + Mnemonic + Enter + Esc where the selected action opens a new form the focus is not put back into the input field.
We'd be very pleased if those issues could be fixed too.
Thanks
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,080
|
Hi,
We are aware of first problem and we are looking into it.
For the second problem, there might be not be a simple solution from our end. This could still be due to the browser engine runs in a different process as we have already discussed in your other thread. So the easiest solution might be for you to change your code to explicitly set the focus.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 10/24/2018
Posts: 97
|
Have you found a solution yet to the first problem?
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,080
|
Hi,
Not yet. To completely resolve the first issue requires significant code changes on our end. Currently the browser engine posts certain keyboard messages to the host application without waiting for it to return. The benefit of this approach is that it has minimum impact on the browser engine itself, particularly it would not block the browser engine's event flow while the same keyboard events is going through the host application's event flow. The drawback is the same keyboard event can be processed on both sides. In order to permanently resolve this issue, we need to block the browser engine and wait for the host application to return to tell the browser engine whether it has "consumed" the specific keyboard events. Currently there are several challenges to this:
1. It will block the browser engine and it can have other implications that needs to be thoroughly evaluated and tested (for example, if part of the the browser engine code is re-entered while waiting for the host application to respond);
2. Currently there is no public interface that can tell us whether the keyboard event has been "consumed" by the Windows Forms shortcut/filter mechanism. So we will have to look for a "hack" to achieve that;
3. A lot of keyboard events works by sequence. For example, "Alt + F" is a sequence of two keydown events. Only at the second keydown event the host application would decide that it will handle it. This means the first event (Alt down) will still be duplicated;
In order to resolve the keyboard issue, we need to resolve all these issues. Because of the complexity of this issue and we are already at the end of the 2018 release cycle, we will try to address this issue in our 2019 release cycle. And if we can not find a reliable solution for all the above issues, we may not be able to resolve this issue.
Thanks!
|
|