I have a .NET c# form with a tabcontrol on the base form. This tabcontrol is absolutely loaded with sub controls and tabs. If I launch my application and immediately open another window (in my app), I can wait about 3-5 seconds and the tabcontrol in the back of the newly opened window will redraw itself and the areas that get refreshed are actually painted through the above window. Almost as if the tab control is redrawing itself through the window above it.
I've looked into every event on the tabcontrol I can find, and nothing is getting called when it is refreshing. So there's nothing simple to unhook to prevent this.
Any ideas how I might solve this one?
Turns out, my computer is the only one that does it. I've tried this application on a couple other computers, and they all run it just fine. Very strange indeed.
Related
I'm making a WinForm app in C# (Visual studio) for fun. I came across a low-priority problem. It doesn't affect how the app works. But...
On the starting page, I have a button to open a Form1, inside Form1, there's a button to open a Form2 and so on.
At runtime, when I open a form, its parent form does not close and every form is a separate tab in the task-bar. As the layers grow, I'll have more-than-acceptable amount of tabs down there...
Is there a way to have only 1 tab?
I've tried:
Adding a parentForm.close() line when opening the form, but that was bad.
Instead of creating another form, putting everything in a panel, and bringing out another panel using code, but if there are too many layers, the code gets ridiculously long.
There has to be a simpler way right? Please shed some light.
Yes, you have a property in every form called ShowInTaskbar which is true by default. You can change that in the form properties under Window Style section or changing it by code manually:
Form2.ShowInTaskbar = false;
Form2.ShowDialog();
Configure to false all forms but the first one in order to achieve your desired behaviour.
Make sure your opened forms are dialogs or you are put them on top so user can never get in the situation where the form is behind and they cannot close it.
Anyway, with a proper form parenting configuration (if it fits your needs) you won't need this, as children forms won't appear in the taskbar.
If a form is parented within another form, the parented form is not displayed in the Windows taskbar.
Make sure you check the MSDN Documentation about this.
I have a CefSharp browser added as a control to a WinForms panel. This is fine on first load - the browser works as expected.
This application is regularly minimized to the taskbar, which is done by calling hide() and show() on the form. This works fine for the form, and worked fine with an embedded Internet Explorer browser (the default WebBrowser control)
However, when I hide/show the form, the CefSharp browser doesn't seem to be re-drawn along with the Form. Right clicking where the browser should be shows the Form's context menu, rather than the browser's context menu, which suggests to me the browser is not attached to that form, rather than the webpage within the browser is being incorrectly drawn.
I initially assumed that it was being invalidated and needed to be redrawn, and have tried a variety of Show, Invalidate, Refresh, Update method calls on the Form, the Panel, and the Browser itself. I've also tried clearing the panel controls and adding the browser again... none of these things seem to work.
When debugging, the browser object is present, has the same URL and parent, is still showing "fill" as the dock mode, has sensible looking height/width sizes etc, so it doesn't look as though it's been detached in some way from the parent etc, it's just not being re-drawn when the form is shown again
Is there a "correct" method for hiding and showing a form containing a CefSharp browser, or some other way of forcing the browser to redraw, that I'm missing?
So here's my own solution, found with some help from Çöđěxěŕ in the comments (who also points out that using Show() and Hide() is not the correct way to show/hide a form at all, instead use WindowState)
In my case, the problem arose from use of Form.ShowInTaskbar
When setting Form.ShowInTaskbar to False (eg don't show the icon for my app when I've just minimized it to the taskbar tray), the browser control seems to get confused about which form is the parent, which appears to be related to the Form.Handle changing.
My solution was to set ShowInTaskBar as false on application load (so the application is never in the taskbar) or not to set it to false on minimize (so it is always in the taskbar when minimized to the system tray). Neither of these are an ideal solution, but they work with the caveat that you have to have the app always hidden, or never hidden.
Presumably it would be possible to re-assign the parent properly on maximize
Use
this.WindowState = FormWindowState.Maximized;
Please see the scrrenshot
I am using WPF ribbon control of Microsoft. I have three tabs with each tab loading different WPF user-controls. I used a splash screen until the main window is loaded. After main ribbon window is loaded, once the user click another Ribbon-Tab it takes 3 - 4 seconds for that tab to be rendered and displayed. However this happens only for the first time. After that switching tabs don't show any delay.
Additional info: I initialized all user controls before the window is rendered, including the user-controls used in all tabs.
I found a hack by moving the window out of the screen when launched and then bring back after switching all tabs programatically. However I read that in Windows 8 if you move the window out of screen the Window operations are suspended in memory.
How to make the tab switching and UI responsive? All suggestions are welcome.
I could'nt entirely avoid the delay, however I was able to mitigate the issue by putting a processing rotating icon overlay while changing tabs. This can be done by calling dispatcher.invokelater on the UI thread while user clicks other tab, and closing the icon when the new tab is loaded.
I am using WinForms for a C# project and my main form has a simple button that uses ShowDialog(this) on a second form to show it.
Like this:
if (myParameterForm.ShowDialog(this) == DialogResult.OK)
{//stuff happens}
As per my requirements, when the child form is visible, you cannot access the parent form.
For the past year this child form has been the bane of my application as it mysteriously manages to hide behind its parent form from time to time. The reason this is such a big problem is because the software is designed to be used from a touchscreen kiosk, so the user only has access to a touch-screen, but the child form has locked input from any form but itself till it is acknowledged (closed with ok or cancel).
On load the child form uses "this.TopMost = true" just in case, I added this as an effort to fix my problem.
I use no other visualizing functions on the child form, the thread calling the form literally waits there till the form is closed.
Since the user has no access to a keyboard, or anything but a touchscreen I'm miffed as to how the child form manages to hide behind the parent form. I actually have been unable to replicate the behavior, and have only seen it as a result of responding to service requests.
I want to avoid using a timer to continually check if the form is TopMost because it just seems wrong. Should I reconsider? What event could possibly be occurring that is banishing my child form backstage?
I've tried using the search, but as far as I can tell I'm doing this correctly... Assuming that there is some sinister 3rd party application causing occasional hijinks, what is the best way to detect and rectify this situation automatically without throwing in a periodic check? I am not sure that the VisibleChanged event is what I'm looking for.
I can reproduce the behavior you are describing by minimizing the child window when it is displayed using ShowDialog. Is it possible that something is minimizing the child window? You could try disabling the control box for the child window to see if that helps. I would probably also set ShowInTaskbar to false for the child window (for usability reasons).
I would probably just implement the child form as a dynamically loaded user control instead. When you need it just load it on top of everything else. This way your main window is always in focus and the content you want to display is on top. this will obviously be a bit of work, but judging by the fact that this has been a problem for a year, you probably don't mind the work if it fixes the problem. There may be more intricacies that you'll have to deal with(i.e. having to make all other controls invisible until the child is done, etc.) but I think this is the easiest and most reliable fix.
In my experience TopMost windows and modal dialogs never behave very well ... as you can lock yourself out if a TopMost window happen to cover the modal dialog control. Are you applying TopMost to the main window anywhere in your code?
I have a similar problem to this question regarding painting of wpf controls
The application I work on is a rather large Windows forms threaded application with several wpf user controls throughout the application. The problem occurs in a plugin of the application where a third party c++ library is called on a separate thread, WndProc is overriden to get the progress updates from the third party library. I have yet to determine the exact scenario that causes the problem but similar to the above mentioned question, after a few runs the wpf controls fails to paint and update.
Setting the width of the elementhosts does solve the painting issue for most of the controls but after this all the wpf controls in the application seems to become 'unresponsive' - visually... the progress bars fails to show progress (though the value does change), scrollbars does not respond, selecting an item in the listview does not highlight it(it does get highlighted after resizing and it does actually get selected - you just can see it is selected) the treeviews does not paint after the resizing, it only shows a black background where the treeview should be (though when I click on the items where they should be in the treeview, the events does get trigerred)
I know I should probably find out the root of the problems that causes this first (its hapening rather randomely and is hard to trap) - allthough putting a breakpoint in the WndProc method does seem to cause it to fail on a regualar base...
What I was hoping for is a way to 'reactivate'/refresh all the other controls throughout the application... I am an intermediate wpf, c# developer and dont really know enough yet about the messaging and events that happens in the background to use them effectively ... my thought is that some event or message that tells wpf to redraw must be broken or interrupted or something - how can I determine what is broken and maybe reactivate it??
Any advice will be much appreciated...
Thank You
It could be that the event that causes the WPF control graph render is never being processed because of that WndProc override.
Since you are inter-oping with WinForms, you can force the events to process by performing a call to Application.DoEvents(); somewhere. Perhaps after you update the progress bar.