Develop Reference

C# Excessive Repainting of WebView2 Control after Applying NativeWinAPI Styles

Having experiences various forms of flickering and graphical glitches, I searched online for possible solution. The only thing that worked straight away was accepted solution using NativeWinAPI from post just below:
Avoid Flickering in Windows Forms?
Inserting this code in the main form of the application and keeping handle for 'this' practically eliminated every issue I had with graphics.
At least until I included a web browser (WebView2 Control). This control along side with the code from the post causes the control itself to constantly repaint itself. This in turn causes graphical issues within entire User Control that is parent to the WebView2. Other controls flicker in and out, which is super annoying and unpleasant.
Having spent hours(days really) trying to figure out what is wrong and practically rewriting entire project, the issue was located and it disappears straight after disabling function that sets the window style.
I am fairly certain that WebView2 Control is the only control having issues as I created OnPaint functions that write to console every time that the control was repainted, and disabling webview2 stops other controls from being repainted, while when enabled I get 100's of repaints within few seconds.
The problem is that disabling those changes makes the application look even worse with all the flickering and graphical glitches that it was fixing before.
I do not understand what the code from the link exactly does (too advanced/complex for my current knowledge). If anyone could help me figure out how to solve the issue I would really appreciate it.
Update:
I created a small demo project for anyone interested in addressing this.
It is a 7zip of the project placed on google drive:
FlickeringDemo.7z
Microsoft Edge Canary Browser is required for WebView2 to work correctly:
Download Edge Canary Here
Main form has bool flag that control graphical improvements and flickering. Simply set it to true/false to observe the difference.
Debug.WriteLine(); - will output Paint Event counter into console in Visual Studio.
bool FlickerEnabled = false;
public MainForm()
{
InitializeComponent();
if (FlickerEnabled)
{
InitialiseGraphicalFixes();
}
}

I was having the same problem in my project and I've managed to solve it.
In the provided FickeringDemo.zip sample, to stop flickering with that version of WebView2 (1.0.664.37) you should set to true the DoubleBuffered property in all of your .Net Controls; see code below for an example on how to do it.
Another thing that I've found is that this fix stops to working in WebView2 1.0.774.44; in that version the rest of your controls will not flick, but the WebView2 will flick a lot. I didn't find a way to solve it...
public partial class WebViewControl : UserControl
{
...
public WebViewControl()
{
...
//the fix to solve flicker if the WS_EX_COMPOSiTED is set on the top window
SetDoubleBuffered(this, true);
}
private void SetDoubleBuffered(Control control, bool value)
{
try
{
control.GetType().GetProperty("DoubleBuffered", BindingFlags.NonPublic | BindingFlags.Instance).SetValue(control, value, null);
}
catch
{
}
foreach (Control child in control.Controls)
{
SetDoubleBuffered(child, value);
}
}

can't get form to remain on top, in .net

I can't get a form to remain on top, in .net
I have checked How to make form always on top in Application and the answer there mentions form1.TopLevel = true; and I've checked How to make a window always stay on top in .Net? and it says Form.ActiveForm.TopMost so i've tried Form.ActiveForm.TopMost = true; and this.TopMost = true;
private void Form1_Load(object sender, EventArgs e)
{
this.TopLevel = true; //default anyway
Form.ActiveForm.TopMost = true;
this.TopMost = true;
}
But as you can see, a notepad window or any window can cover it.
Added
I have tried every suggestion made so far.
In response to Han's advice, "Of all the possible places to set TopMost property, the Load event is the worst. It should be set in the constructor, so the window gets created top-most right away. Or it should be set after it is visible, so after the Load event. Use the constructor. ". I tried putting those lines in the constructor.
public Form1()
{
InitializeComponent();
this.TopLevel = true; //default anyway
//Form.ActiveForm.TopMost = true; (commented to prevent a System.InvalidOperationException, presumably the form isn't yet active at this stage)
this.TopMost = true;
}
And the the other two suggestions, from others-
I tried setting the Form's TopMost field in the designer to True.
And running the EXE directly rather than just clicking play in visual studio.
Same issue.
And if you find that hard to believe, i've taken a 1min video here showing just that. https://screencast-o-matic.com/watch/cbXXrw2oTN
A potentially useful comment was mentioned..
Steve comments - "OK something definitively odd is happening here. I have tried to create a simple topmost form using linqpad and at the first run I get your same behavior. At the second run though everything works as expected."

A workaround, is this, following on from Han's point to put not put it in Load. Load is indeed too early. I've been finding that (at least on the system with the issue), The Constructor is also too early. I find that putting it in the Shown event, works.
One possible solution to this, is to run this patch, https://support.microsoft.com/en-us/help/2587473/topmost-windows-are-not-always-in-the-topmost-position-in-windows-7-or But be warned, if you want to uninstall it, I have some doubts whether it uninstalls correctly. And it's also not clear to me whether the patch is working or working sporadically. It likely works but it's hard for me to tell.
One commenter thought it's just my system, though that's not the case, as Steve ran into the same issue the first time he ran it. I find it may be most prone to happen after windows restarts, So, the program is running very fresh. But I find that putting that code in the Shown event, is fine and the form stays on top.
I tried instead of TopMost=true, using SetWindowPos, to set the window on top, I tried it fairly early like in the constructor, and late, like in the Shown event or on a button click, and I found it was fine in the Shown event or on a button click. So the issue was related to the TopMost=true line, or SetWindowPos line, firing too early, prior to the window it is setting appearing.
When calling SetWindowPos later one can use either this.Handle or GetForegroundWindow(), the former is easier as it's native. When calling it earlier one must use this.Handle. And using this.TopMost=true avoids all winAPI calls completely.
So in short, you could try the patch, though note that it might not uninstall right.. Or you can try the workaround of putting this.TopMost=true in the Shown event of the form.

C# MSTEST Coded UI Automated Test Fails While Identical Manual Test Passes

I've Googled and Binged and Yahoo'd and even Dogpiled. I found mostly Python, PHP, and Ruby that don't apply. Only one item shows up (from 2012) but it has no answer: unit test fails in r# but passes in mstest
I have two tests that work exactly as recorded. For one, when the test gets to the Submit button, the app says the page isn't ready to be submitted and the Submit button remains disabled. For the other, the Submit button is enabled, but the page does nothing. When I run the exact same actions manually (using keyboard and mouse) with identical data (or with different data), the Submit buttons on both pages work and both pages process.
I've run the tests to the point where the Submit buttons are clicked, but nothing happens when I manually click them, either. I've tabbed from one field to the next thinking it might be an event not firing, but no.
Here's what I've found: If the automation opens the page, the Submit buttons will not work. If even one item on the page is entered or selected by the automation, the Submit buttons will not work. BUT: If I run the automation to the point BEFORE the page opens, then if I click to open the page and manually keyboard and mouse the entries, and then manually mouse-click the Submit button, it will work.
The tests were recorded in MTM and imported into Visual Studio 2012. I've tried re-importing them, and I've manually recorded the steps using Visual Studio.
We're now thinking there's some unexpected interaction between the testing software (MSTest) and the JavaScript in the pages. We've coded (Coded UI) 11 other pages in the application. All 11 application pages use the same basic architecture and the same controls. We testers are thinking the JavaScript might be broken (missing closing brace, missing pair of parentheses, missing a semi-colon, a line-break in the wrong place, something).
There is absolutely nothing unique about these tests. They are among the simplest tests I've ever coded. One of them only has four input fields. I've coded nothing manually; The UIMap.cs file is empty. It's all in the UIMap.Designer.cs based on the UIMap.UITest file.
Here is the significant portion of my Coded UI Test Class (variable setup and try-catch logic omitted):
try
{
User.OpenBrowser(TestContext);
this.UIMap.ClickFeesButtonInSecondaryMenu();
this.UIMap.ClickAddPaymentButton();
this.UIMap.OpenYearDropdownAndSelect2016();
this.UIMap.Type1234InCheckNumber();
this.UIMap.Type275InTotalAmount();
this.UIMap.SelectBusinessFees();
this.UIMap.SelectInstructorFees();
this.UIMap.ClickSubmitButton();
User.CloseBrowser(TestContext);
}
catch . . . .
Here is part of my UIMap.Designer.cs:
public void ClickFeesButtonInSecondaryMenu()
{
#region Variable Declarations
HtmlHyperlink uIFeesHyperlink = this.UIInternetExplorerWindow.UIDocument.UIFeesHyperlink;
#endregion
// Click 'Fees' link
Mouse.Click(uIFeesHyperlink, new Point(22, 21));
}
public void ClickAddPaymentButton()
{
#region Variable Declarations
HtmlHyperlink uIAddPaymentHyperlink = this.UIInternetExplorerWindow.UIDocument1.UIAddPaperPaymentHyperlink;
#endregion
// Click 'Add Payment' link
Mouse.Click(uIAddPaymentHyperlink, new Point(84, 15));
}
public void OpenYearDropdownAndSelect2016()
{
#region Variable Declarations
HtmlHyperlink uIItem2017Hyperlink = this.UIFeeInternetExplorerWindow.UIFeeDocument.UIItem2017YearYearPane.UIItem2017Hyperlink;
HtmlDiv uIItem2016Pane = this.UIFeeInternetExplorerWindow.UIFeeDocument.UIItem2016Pane;
#endregion
// Click '2017' link
Mouse.Click(uIItem2017Hyperlink, new Point(149, 20));
// Click '2016' pane
Mouse.Click(uIItem2016Pane, new Point(124, 3));
}
public void Type1234InCheckNumber()
{
#region Variable Declarations
HtmlEdit uICheckNumberEdit = this.UIFeeInternetExplorerWindow.UIFeeDocument1.UICheckNumberEdit;
#endregion
// Type '1234' in 'Check Number' text box
uICheckNumberEdit.Text = this.Type1234InCheckNumberParams.UICheckNumberEditText;
}
. . . and so on until you get to . . .
public void ClickSubmitButton()
{
#region Variable Declarations
HtmlInputButton uISubmitButton = this.UIFeeInternetExplorerWindow.UIFeeDocument1.UISubmitButton;
#endregion
// Click 'Submit' button
Mouse.Click(uISubmitButton, new Point(27, 17));
}
I've only been doing C# MSTEST Coded UI just over a year, but I have three other automators here with tons more experience than I have, and this problem is new to us all. We've looked at everything we can think of, but no joy. Has anyone seen this? What causes this behavior? Most importantly, is there a fix?

Because you mentioned that you think the JS may be broken, that leads me to believe that perhaps some sort of AJAX is going on in the background after clicking the button. If that is the case, please see this question to see if it applies to your case.

TreeView node icon changes when selected only on custom icons in C#

So I have a TreeView in C# and I'm loading icons for folders via P/Invoke. It's working, but on icons which are custom (so to speak), they change to some weird icon, as seen in the image below:
On "Regular" folders, i.e. ones without custom icons, this doesn't happen. Also on things like my HDD icons, it doesn't happen. This is the code I'm using to set the icon key
ImageKey = node.FileInfo.UniqueIcon;
SelectedImageKey = ImageKey;
As you can see, there's no way SelectedImageKey is different from ImageKey. However, the icon is still being set as the 0th index of the ImageList.I have confirmed via the debugger that the keys are staying the same, after the object is added.
So any ideas why this would be happening only for some icons?
Thanks.
Update
I found a workaround, but I'm not calling it a solution. If I add this to my code:
private void FolderTree_BeforeSelect(object sender, TreeViewCancelEventArgs e) {
e.Node.SelectedImageKey = e.Node.ImageKey;
}
I'm not calling it a solution, because that command only has to run once for it to work. I know that because if I put it on the AfterExpand event, then after it does it for one bad one, all the others work after that, even before they're expanded. So it's like something just isn't clicking until after, and resetting just one makes all others work.

ToolStrip with custom ToolStripControlHost makes tab order focus act weird

I'm experiencing some strange behavior. Let me try to explain, I stripped my code down to the bare minimum and I'm still having the problem. So first of all, I'm using VS2013 with .NET 4.0 and I'm on Windows 8.1.
So I have a custom UserControl with a TextBox that's being used through a ToolStripControlHost, if I focus on this textbox and hit TAB, it only cycles through the controls to the LEFT of this textbox. If I have it focused and hit SHIFT+TAB, it cycles through the buttons to the right of it.
So this is an example of my form. The textbox in the middle is a custom control. My code (as simplified as possible) looks like:
[ToolStripItemDesignerAvailability(ToolStripItemDesignerAvailability.ToolStrip | ToolStripItemDesignerAvailability.StatusStrip)]
public class ToolStripTestControl : ToolStripControlHost
{
public ToolStripTestControl() : this(new TestControl()) { }
public ToolStripTestControl(Control c) : base(c) { }
}
public class TestControl : UserControl
{
private TextBox _textBox = new TextBox();
public TestControl()
{
_textBox.Dock = DockStyle.Fill;
this.Controls.Add(_textBox);
}
protected override Size DefaultMinimumSize { get { return new Size(100, 22); } }
}
Simply creating a new WinForms (.NET4) project and following these steps will allow you to replicate the problem:
Add new class file and paste the code above.
Build
Add a ToolStrip to your form
On the ToolStrip add a Button, my custom control, and another Button (through the designer is how I've been doing it)
Run
Once running...
Focus in the custom control
Hit TAB a few times, it should only focus on controls to the left.
Hit SHIFT+TAB a few times and it will only focus to the right.
Does anyone know what the problem is - or how I can fix this? I've been tearing my hair out all day trying to fix this. I finally stripped my code down and I can't seem to get it to work. I even tried overriding much of the OnEnter/OnGotFocus functionality and doing it myself, but that became a nightmare.
Thanks!
Update1: So a few extra tid-bits.
If I change the custom control to inherit from TextBox instead of UserControl, tabbing/focus works as expected.
If I change it to be a Control instead of a UserControl the tabbing works fine, as well, however the focus never gets inside my inner TextBox - the focus seems to be lost (or presumably on the outer parent control but not being passed down to the inner TextBox).
I do see a MS Connect item added that describes this problem from 2009, but this link only seems to work if I'm NOT logged in to Microsoft Connect. Which means, I can't vote on it or comment... http://connect.microsoft.com/VisualStudio/feedback/details/472592/tab-cycling-through-controls-with-usercontrol-on-toolstrip-doesnt-perform-as-expected

The .NET 2.0 ToolStripItem classes have been a major bug factory. They are window-less controls, but reproducing the exact behavior of a Windows window isn't that easy. There is an enormous amount of code underneath, most of it internal so you can't tinker with it. And with quirks when they don't emulate the behavior of a window perfectly. You could call them "airspace" issues, pretty similar to the kind of problems that WPF has.
The airspace issue here is focus, entirely unambiguous for a true window but it needs to be faked for a ToolStripItem. It is actually the item's parent that has the focus, it needs to be emulated for the item. It is the transition that bytes, ToolStrip expects a window-based control to have a reliable Focus property.
Trouble is, your custom host doesn't. It is the inner control that has the focus. This could arguably be blamed on an omission in the ToolStripControlHost class. Probably. The trouble with emulating a window, there's never enough code :)
Anyhoo, fix your problem by adding this sliver of code to your host:
public override bool Focused {
get { return _textBox.Focused; }
}