Welcome Guest Search | Active Topics | Sign In | Register

Shortcuts are executed on the wrong forms Options
PS
Posted: Friday, May 31, 2019 10:41:56 AM
Rank: Advanced Member
Groups: Member

Joined: 10/24/2018
Posts: 97
Hello,

We are facing an issue where we have a form with a webcontrol on it, and a textbox for our textsearcher, and we can open a new form modally on top of it. Now when we press Ctrl+F we want to show the textbox, this works fine if we only show the first form, but as soon as we open the form modally, then the textbox is still shown when we press Ctrl+F, even though we do not expect that at all.

We have managed to reproduce a sample application, first I will list the code we are using and then I will list the steps we took to reproduce this issue.

Quote:

using System;
using System.Collections.Generic;
using System.Drawing;
using System.Linq;
using System.Threading.Tasks;
using System.Windows.Forms;

using EO.WebBrowser;
using EO.WinForm;

namespace EOTestShortcut
{
static class Program
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(CreateNewForm());
}

private static Form CreateNewForm()
{
var form = new Form
{
ShowInTaskbar = false,
Size = new Size(1280, 1024)
};

var button = new Button
{
Dock = DockStyle.Bottom,
Text = "Open search"
};
button.Click += (sender, e) =>
{
Cursor.Current = Cursors.WaitCursor;
var searchForm = CreateSearchForm();
searchForm.ShowDialog(form);
};

var webView = new WebView();
webView.LoadUrl("https://www.google.com");

var searchCommand = CommandIds.RegisterUserCommand("Search");

webView.Shortcuts = new EO.WebBrowser.Shortcut[]
{
new EO.WebBrowser.Shortcut(searchCommand, KeyCode.F, true, false, false)
};

webView.Command += (sender, e) =>
{
if (e.CommandId == searchCommand)
{
System.Diagnostics.Debug.WriteLine("Ctrl+F pressed in webbrowser");
var random = new Random();
button.BackColor = Color.FromArgb(random.Next(256), random.Next(256), random.Next(256));
e.Handled = true;
}
};

var webControl = new WebControl
{
Dock = DockStyle.Fill,
WebView = webView
};

form.Controls.Add(webControl);
form.Controls.Add(button);

return form;
}

private static Form CreateSearchForm()
{
var form = new Form
{
ShowInTaskbar = false,
Size = new Size(800, 600)
};

var label = new Label
{
Dock = DockStyle.Fill
};

var textBox = new TextBox
{
Dock = DockStyle.Bottom
};
textBox.PreviewKeyDown += (sender, e) =>
{
if (e.KeyCode == Keys.F && e.Modifiers.HasFlag(Keys.Control))
{
label.Text = "Ctrl+F pressed";
}
};

form.Controls.Add(label);
form.Controls.Add(textBox);

return form;
}
}
}


How to reproduce:
1. Wait for everything to be loaded.
2. Press Ctrl+F, observe that the "Open search" button changes background color, as intended.
3. Click the "Open search" button, observe that a new form is opened modally, as intended.
4. Press Ctrl+F, observe that the "Open search" still changes background color! This is not intended, we have another form on top, so the underlying form should not get any events anymore.

This situation only reproduces when ShowInTaskbar is false for both forms, so we suspect that it is crucial for this issue, however we need to use exactly this situation. Currently we cannot use any shortcuts in our application and therefore we cannot ship it for production.

We are facing several issues due to this bug in our actual implementation, for example when we show a new form modally on top of the form with the webcontrol on it and we have a listview on it where the user can search with Ctrl+F, then it will now attempt to open the search box in the webbrowser form, instead of in the listview form.

To be absolutely clear: We want that pressing Ctrl+F in step 4 has no effect on the underlying form, that is the background color of the "Open search" button should not be changed for example.
eo_support
Posted: Tuesday, June 4, 2019 12:48:54 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
Thanks for the code. We have confirmed this to be an issue and will be fixed in our next build. We will reply here again once the new build is available.

PS
Posted: Friday, June 21, 2019 5:06:31 AM
Rank: Advanced Member
Groups: Member

Joined: 10/24/2018
Posts: 97
We can confirm that this issue has been fixed with the latest build.
eo_support
Posted: Friday, June 21, 2019 9:39:07 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
Great. Thanks for confirming the fix and sorry about the issue.


You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.