|
|
Rank: Advanced Member
Groups: Member
Joined: 10/24/2018
Posts: 97
|
Hey again, is there any news or estimated time frame for when something will be ready? Then we can adjust our internal estimated based upon that.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,080
|
Hi,
Sorry about the delay. We have finally have a reasonable stable test build. Please see your private message for the download location.
We were trying to implement a significant revamp on input routing in this build and ran into some problems. The majority of the issues have been worked out in this build, even though there are a few minor issues that still need to be ironed out. The new input routing mechanism should work much better than the old version because it routes every input message through .NET first. So many built-in Windows features such as menu item hot keys should now work automatically even though the input actually occurred in the child process.
We did implement the AllowSetForegroundWindow call you recommended and it seems to be working (big thanks!) We have verified this test build with the original code you posted and it seems to be working fine. Please verify this on your end.
We expect the release built to be out in one to two weeks. We will update this thread again once the final build is out.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 10/24/2018
Posts: 97
|
Thank you for the test build :)
We have our initial feedback ready, the good news is that AllowSetForegroundWindow seems to have solved the threading and stacking issues!
Unfortunately it also seems that several issues have been introduced, which I would not expect in a reasonable stable test build.
1) The alt+mnemonic in the top menu almost works, a case that does not work is when you for example the "View" menu which has a mnemonic on V with Alt+V while you hold Alt down.
2) In any input field in the browser there is a high likelyhood that the typed character will be duplicated, this likelyhood seems to improve when you type faster or when you press two keys at the same time, it is hard to believe that this issue escaped your internal testing so I assume that you are already aware of it.
3) Selecting text by clicking and holding down the left mouse button and then moving the mouse and releasing the left mouse button does not work. Currently you can only select text by double-clicking on a word.
These issues have both been verified in our own application and in the provided test program at the start of this post (from which the MouseDoubleClick and TextChanged handlers can be removed as they were only used for the AllowSetForegroundWindow problem). They all need to be fixed before we can continue internal testing.
We're hoping to receive a new test build soon and will test again as soon as it's received.
Kind regards
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,080
|
Thank you very much for the detailed feedbacks. This is just to let you know that we have posted a new build that should resolve these issues for you. Please see your private message for the download location.
Please take a look and let us know how it goes.
|
|
Rank: Advanced Member
Groups: Member
Joined: 10/24/2018
Posts: 97
|
We have another bit of partial feedback ready at this point, which is that unfortunately Alt + Mnemonic is still not working correctly.
When I press Alt, I expect that the first item of the top menu is highlighted and has the focus, and then a mnemonic should select the correct menu.
I believe you have fixed this already some time ago, but it seems like the recent update has broken this feature.
It will be a bit before I can give the next feedback as we're currently working on resolving some issues internally that seem to correlate with the improved input handling, but hopefully I can test a new build soon and at least verify that that works.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,080
|
Hi,
We did test this in our own test and it seems to work fine. Can you send a test project to us?
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 10/24/2018
Posts: 97
|
I tested it using the same test program as in the first post of this thread, when the (default) google.nl site is loaded and you focus the search field and then press Alt, then I expect the File menu to be highlighted such that subsequently pressing F will open the File menu and pressing V will open the View menu.
Please observe that it works if you do the same in the textbox below the webview.
|
|
Rank: Advanced Member
Groups: Member
Joined: 10/24/2018
Posts: 97
|
Unfortunately we have noticed a new issue, which we cannot fix as it seems to be caused by the code from EO. I'll include the code snippet for completeness, but it has not really changed since the first time. Quote:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading;
using System.Threading.Tasks;
using System.Windows.Forms;
using EO.WebBrowser;
using EO.WinForm;
namespace EOTest
{
static class Program
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(CreateTestForm(true));
}
private static Form CreateTestForm(bool displayBrowser)
{
var form = new Form1();
var menuStrip = new MenuStrip
{
Dock = DockStyle.Top
};
var fileItem = new ToolStripMenuItem("&File", null, new ToolStripMenuItem("Open"), new ToolStripMenuItem("Quit"))
{
ShortcutKeys = Keys.Alt | Keys.F,
ShowShortcutKeys = true
};
menuStrip.Items.Add(fileItem);
var viewItem = new ToolStripMenuItem("&View", null, new ToolStripMenuItem("Zoom in"), new ToolStripMenuItem("Zoom out"))
{
ShortcutKeys = Keys.Alt | Keys.V,
ShowShortcutKeys = true
};
menuStrip.Items.Add(viewItem);
form.Controls.Add(menuStrip);
if (displayBrowser)
{
var webControl = new WebControl
{
Dock = DockStyle.Fill,
TabStop = false
};
var webView = new WebView
{
Url = "https://www.google.com"
};
webView.MouseDoubleClick += (sender, e) => form.Invoke((MethodInvoker)delegate () { ShowFormInNewUIThread(sender, webControl, form); });
webControl.WebView = webView;
form.Controls.Add(webControl);
}
else
{
var textArea = new TextBox
{
Dock = DockStyle.Fill,
Multiline = true
};
form.Controls.Add(textArea);
}
var textBox = new TextBox
{
Dock = DockStyle.Bottom
};
form.Controls.Add(textBox);
return form;
}
private static void ShowFormInNewUIThread(object sender, WebControl webControl, Form originalForm)
{
new Thread(() =>
{
var newForm = CreateTestForm(false);
var nativeWindow = new NativeWindow();
nativeWindow.AssignHandle(IntPtr.Zero);
newForm.ShowDialog(nativeWindow);
}).Start();
}
}
}
The issue that we are experiencing is that whenever we open a form in a new thread (in our own application, and in this test program via the MouseDoubleClick handler of webView) everything first goes fine, the form is opened on top of the previous form, but now we noticed an issue when closing the new form. When we close the new form, then the original form suddenly scrolls to the top. This seems to be caused because the focus is set to the first focusable element on the original page. This is a disturbing issue which makes it difficult to work with the browser in some contexts, so we hope that it can be fixed.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,080
|
Hi,
We have a new build that should fix both of these issues (Alt key issue and scrolling issue). Please see your private message for the download location.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 10/24/2018
Posts: 97
|
Thank you for your quick response! The two reported issues are fixed, unfortunately there are new issues. The first issue seems to be introduced in this new build. When I focus a text input inside the browser, and then press Alt the menu bar correctly gets focused, then pressing the correct mnemonic focuses the correct menu, but whenever you input a key that does not match a mnemonic, it gets sent to the input inside the browser. This should not be happening as the form's toolstrip menu has the focus, and the keys should be eaten by the toolstrip menu. The second issue is more serious, and also reproduces in the previous V2019.0.42.0 build. It reproduces with the following code: Quote:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading;
using System.Threading.Tasks;
using System.Windows.Forms;
using EO.WebBrowser;
using EO.WinForm;
namespace EOTest
{
static class Program
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(CreateTestForm(true));
}
private static Form CreateTestForm(bool displayBrowser)
{
var form = new Form1();
var menuStrip = new MenuStrip
{
Dock = DockStyle.Top
};
var fileItem = new ToolStripMenuItem("&File", null, new ToolStripMenuItem("Open"), new ToolStripMenuItem("Quit"))
{
ShortcutKeys = Keys.Alt | Keys.F,
ShowShortcutKeys = true
};
menuStrip.Items.Add(fileItem);
var newBrowserToolStripMenuItem = new ToolStripMenuItem("New browser");
newBrowserToolStripMenuItem.Click += (sender, args) => {
var newForm = CreateTestForm(false);
newForm.ShowDialog(form);
};
var viewItem = new ToolStripMenuItem("&View", null, newBrowserToolStripMenuItem, new ToolStripMenuItem("Zoom in"), new ToolStripMenuItem("Zoom out"))
{
ShortcutKeys = Keys.Alt | Keys.V,
ShowShortcutKeys = true
};
menuStrip.Items.Add(viewItem);
form.Controls.Add(menuStrip);
if (displayBrowser)
{
var webControl = new WebControl
{
Dock = DockStyle.Fill,
TabStop = false
};
var webView = new WebView
{
Url = "https://www.google.com"
};
webView.MouseDoubleClick += (sender, e) => form.Invoke((MethodInvoker)delegate () { ShowFormInNewUIThread(sender, webControl, form); });
webControl.WebView = webView;
form.Controls.Add(webControl);
}
else
{
var textArea = new TextBox
{
Dock = DockStyle.Fill,
Multiline = true
};
form.Controls.Add(textArea);
}
var textBox = new TextBox
{
Dock = DockStyle.Bottom
};
// textBox.TextChanged += (sender, e) => form.Invoke((MethodInvoker)delegate() { ShowFormInNewUIThread(sender, null, form); });
form.Controls.Add(textBox);
return form;
}
private static void ShowFormInNewUIThread(object sender, WebControl webControl, Form originalForm)
{
//originalForm.Focus();
new Thread(() =>
{
var newForm = CreateTestForm(false);
var nativeWindow = new NativeWindow();
nativeWindow.AssignHandle(IntPtr.Zero);
newForm.ShowDialog(nativeWindow);
}).Start();
/*if (sender is Control control)
{
control.Focus();
}
else
{
webControl.Focus();
}*/
}
}
}
The issue is that whenever a form is modally started in a toolstrip menu item (point in case: The "New browser" menu item) while the focus is inside the browser (so it can only happen while navigating with Alt+Mnemonic from inside the text input in the browser) the whole application hangs. We think this might also impact your other users as opening a new form modally is a relatively normal operation. Please note that opening it non-modal does work, and that's also what we expect, so that part is correct.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,080
|
Hi,
We have a new build that should resolve both issues. We can positively confirm the first issues (extra key stokes) is resolved. For the second issue, we did find a problem that can cause hang but we are not able to reproduce the issue with your test code as is unless we change CreateTestForm(false) to CreateTestForm(true) in the toolbar item click handler. In theory the issue we fixed could cause hang even when CreateTestForm(false), however changing it to CreateTestForm(true) would make the issue a lot easier to reproduce. Hopefully this is the same issue you experienced. Please confirm it on your end.
|
|
Rank: Advanced Member
Groups: Member
Joined: 10/24/2018
Posts: 97
|
Hey,
Thank you for your quick reply!
The first issue indeed seems to be resolved, toolbar integration seems to work as expected.
The second issue however is not fixed. It also still reproduces in the latest sample code I have provided (on February 8, 2019).
Could you test again?
I'll also add some system specifics in case that matters.
I'm running on Windows 10, with .NET Framework 4.7.2 (Release 461814) installed.
The project is built against .NET 4.7.2 on "Any CPU" bitness.
Though I just changed it to be built against .NET 4.5 as that is actually our target framework for our actual application, but it still reproduces on that version.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,080
|
Hi, Please send a full test project to us by email. See here for more details: https://www.essentialobjects.com/forum/test_project.aspxThere might be some difference between your test project and our test project that we missed. Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 10/24/2018
Posts: 97
|
I've just sent the email, I hope you will be able to reproduce it with this test project.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,080
|
Hi,
We have received the test project and we are not able to reproduce it. Here are our steps:
1. Run the test project, wait for Google's home page to load;
2. Click the search box so it has focus;
3. Press Alt + V to display the "View" sub menu, then down arrow key to select the "New Browser" menu item;
4. A new window opens. This window is modal;
We can still type in the textbox or select menu items in the new window. Can you see if you are doing anything differently than we did?
We use the .49 build.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 10/24/2018
Posts: 97
|
I have just verified again and it still reproduces, it also reproduces on a coworker's PC in our actual application.
The license dialog shows V2019.0.49.0 as version, so it should be the newest.
Actually, I think I just discovered something important!
For step 2 it matters which search/text box you focus. If I focus the text box below the browser, then everything opens up fine. But if I focus and type in Google's search bar and then subsequently press Alt+V, and then open "New browser" via the arrow keys, then everything hangs.
In case it still does not reproduce, please also verify whether the license dialog may have anything to do with it.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,080
|
That is the textbox we focused --- Google's search box, not the textbox below. We tested again and we do not see any problems. :(
|
|
Rank: Advanced Member
Groups: Member
Joined: 10/24/2018
Posts: 97
|
Good afternoon,
We tested again internally, and this bug reproduces exclusively on all machines that have Windows 10 Version 1703 installed.
Could you look into it again and resolve this bug? Then we can continue our internal evaluation.
Kind regards,
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,080
|
Hi,
Currently we do not have any 1703 systems since all our Windows are set to update automatically and 1703 was released more than one year ago. We will see if we can setup a test system with that version. We will reply here again when we have further update.
Thanks!
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,080
|
Hi, We were able to reproduce this issue on Windows 1703 and our next build will work with modal dialog triggered by selecting a menu item. However the root of the problem appears to be a bug specifically on Windows 1703 and we are not able to find a reliable workaround for this bug from our side. The issue occurs when the message loop is blocked across processes (message loop in the browser engine process is blocked by the modal dialog in your process). In this case Windows would stop dispatching input messages for this entire input chain, which causes the modal dialog not receiving any input messages at all. So technically the application is not hanging because it is still actively waiting for input messages, but it just doesn't get any from Windows. In order to break this deadlock, the control must return from your application back to the browser engine quickly (in order to tell the browser engine whether this input message is consumed by your application so that the browser engine will know whether to ignore it or not --- this is essential to avoid the same key strokes are duplicated on both sides like previous versions). We are able to detect the specific case demonstrated in your sample application (user selecting a menu item) and return control to the browser engine immediately in this case before firing the menu item's event handler. So this particular case will work fine in our next build. However there are other cases that we will not be able to detect. For example, if you assign the ShortcutKeys to your newBrowserToolStripMenuItem and then invoke your modal dialog from that ShortcutKeys, then the modal dialog will show correctly (due to the fact that we route the input messages), but the same bug will be triggered and your modal dialog won't receive any more input messages in this case. We have not found a reliable way to detect this case. Additionally, there can be other cases that can trigger this issue --- for example, user could choose to handle MouseMove event and show a modal dialog just for fun, or even invoke another third party DLL or simple APIs that blocks messages flow (such as a simple message box), then the whole issue will be triggered again and it is not possible for us to catch all these cases. Because of this and consider that this issue has already been fixed by later Windows update, we believe the easiest solution is to change your code not to block the message flow. You can simply change your code from:
Code: C#
newForm.ShowDialog(form);
To:
Code: C#
newForm.BeginInvoke(new Action(() =>
{
newForm.ShowDialog(form);
}));
This would allow the control to return to the browser engine immediately and your dialog would be displayed during the next message cycle that does not originate from another process thus avoiding this bug. You can use this workaround in the current release build. Hope this helps. We will reply here again when we post the update build that works for selecting menu item case. Thanks!
|
|