|
|
Rank: Advanced Member
Groups: Member
Joined: 10/24/2018
Posts: 97
|
The fix you've mentioned seems sufficient, thank you!
I actually was not aware that a new version had been released, as apparently there now was a public release.
However we now have issues with the Windows start menu not always appearing correctly, have you had any reports of that before?
We definitely started to notice this since the 2019 build, but we're unsure if the issue was already present in the 2018 build.
The situation only arises when you have the focus inside the webbrowser, and all systems mentioned below use Windows 10.
On my PC, running version 1703, my test application (the same as earlier mentioned in this topic) works correctly. However when I go to the Properties of the executable, go to Compatibility and check "Override high DPI scaling behavior. Scaling performed by: Application" (just as we have in our actual application), then most of the time something that looks like an unfinished Windows start menu pops up for less than a second in my left top corner. So you kind of see a black flash and then it's gone again.
However when a coworker of mine runs it on version 1703, then the start menu does not even open, in neither of the cases.
When another coworker runs it on version 1809 but with his own custom start menu installed (we are not sure if that is relevant), then it works as expected in both cases.
And when another coworker runs it on version 1709, then we get the unfinished Windows start menu issue in either case and always, but not in the bottom left corner.
|
|
Rank: Advanced Member
Groups: Member
Joined: 10/24/2018
Posts: 97
|
Good afternoon, do you have an update about the Windows start menu issues?
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,071
|
Hi,
No. We do not have any update on this issue yet. We are working on a number of keyboard event related issues and are planing to retest your case after that part is done. We will reply here again as soon as we have an update.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 10/24/2018
Posts: 97
|
Good afternoon, I have a new update about the above mentioned start menu issue. After several extensive tests we found out that it has nothing to do with our application as it also reproduces in the sample code mentioned above, though I'll add a newer version of the sample code at the end of this post. The key point though is that this issue does NOT reproduce whenever a debugger is attached to the process containing the WinForms EO WebControl. 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());
}
private static Form CreateTestForm()
{
EO.WebEngine.Engine.Default.Options.DisableGPU = true;
var form = new Form1();
var webControl = new WebControl
{
Dock = DockStyle.Fill,
TabStop = false
};
var webView = new WebView
{
Url = "https://www.google.com"
};
webControl.WebView = webView;
form.Controls.Add(webControl);
Button btn = new Button();
btn.Click += (sender, e) => {
form.Close();
webView.Dispose();
webControl.Dispose();
};
form.Controls.Add(btn);
btn.Dock = DockStyle.Top;
form.CancelButton = btn;
form.FormClosing += (sender, e) =>
{
var dialogResult = MessageBox.Show("You have unsaved changes, are you sure you want to exit?", "Are you sure?", MessageBoxButtons.YesNoCancel);
switch (dialogResult)
{
case DialogResult.Cancel:
case DialogResult.No:
e.Cancel = true;
break;
default:
break;
}
};
var textBox = new TextBox
{
Dock = DockStyle.Bottom
};
form.Controls.Add(textBox);
return form;
}
}
}
So now we do think that the issue is with the EO.WinForms control, and not with our application.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,071
|
Thanks for the update. We will only investigate these issues on recent Windows vrsions (1803/1809) since we know previous versions such as 1703 has problems. It is not practical for us to ghost hunting on every previous Windows build.
|
|
Rank: Advanced Member
Groups: Member
Joined: 10/24/2018
Posts: 97
|
I'm running Windows 10 version 1809 right now, I updated two days ago, and this problem still reproduces.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,071
|
Hi,
We tested this on both 1803 and 1809 and we were not able to reproduce the problem. Our steps are:
1. Right click the exe file, check "Override high DPI scaling behavior. Scaling performed by: Application";
2. Run the exe file;
3. Set focus to the Google search box;
4. Click the Windows icon on the task bar to open the start menu;
We did not notice anything abnormal. Are your steps different?
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 10/24/2018
Posts: 97
|
Good afternoon,
Yes, our steps are different. You need to press the Windows key on the keyboard on step 4, and not use the Windows icon on the task bar.
It should reproduce that way.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,071
|
Yes. We did reproduce this way. We will investigate further and keep you updated.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,071
|
Hi,
We have posted a new build that resolved the Windows key issue in our environment. Please download it from our download page and see if it works for you.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 10/24/2018
Posts: 97
|
Thank you! It works for us now.
Extra question: We deployed the eowp.exe recently and this is our first version update after we did that. When starting with the new .NET assemblies I got an UnauthorizedAccessException, which got fixed after redeploying eowp.exe. Do we always need to update eowp.exe when there is a new version, if no, how do I find out that we do need to update it?
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,071
|
Hi, The easiest way for you to use eowp.exe is to use this method: https://www.essentialobjects.com/doc/eo.base.runtime.initworkerprocessexecutable.aspxThis method will automatically creates eowp.exe (using the file name you provided) and it will check the version of the file if one already exists. If the existing one is the wrong version, then it will rewrite it. That way you don't have to worry about the file version. Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 10/24/2018
Posts: 97
|
Ah, we were unaware that it would also create the eowp.exe file. Unfortunately I don't think it is of much help as we only run into issues on severely locked down environments anyway, so we chose to deploy it next to our application executables as part of our deployment process.
I think I now understand the UnauthorizedAccessException we were getting though, I suspect it was because it tried to overwrite a program inside the Program Files folder.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,071
|
That could be the case. You can also deploy it manually simply by copying eowp.exe into the same directory as EO.Base.dll. This way it will be your responsibility to ensure the version number between these files match. eowp.exe should always have the same version number as EO.Base.dll. As such this file does change every time you update to a new version.
|
|
Rank: Advanced Member
Groups: Member
Joined: 10/24/2018
Posts: 97
|
Okay, thank you!
We have made changes to our workflow to ensure that the version numbers will always match.
|
|