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.
Related
I have a legacy Winform application (quite large and monolithic) where we now host WPF controls for the newer functionality.
After some interaction and updating, I get it into a state were all the WPF controls (only) stop updating. Ie if I set a property in the bound view model, the UI does not update. Also controls such as splitters and sliders do not work. Event if I invoke a WPF dialog, the radio button on it does not work.
All the Winforms controls work fine. It is although there is some WPF layer that has stopped functioning.
I have checked everything I can think of, ie everything occurring on correct threads, rendering in SoftwareOnly etc. Pausing the application, I see no locked threads, or anything else suspicious. I don't see any exceptions.
I am now at a loss on how to diagnose what is wrong here.
Does anyone have any ideas on how I can diagnose such an issue? Ie is there anything common like this that can occur with WPF on Winforms? I have never come across this before!
Thanks in advance for any help here.
[UPDATE1]
I just noticed, if I resize the WPF winforms parent container, THEN the WPF control updates..
I've set my XNA game's DeviceWindowHandle to a PictureBox with Dock set to Fill on a Form, effectively providing the powerful array of .NET controls to my game. I'm aware this comes with a handful of niggly things to clean up, one of which is my problem explained below.
I'm trying to figure out if it's possible to avoid the WM pump pausing when doing things like clicking to drag a ScrollBar control, or right clicking in a TextBox control, this ultimately causes my renderSurface (the dock filled pictureBox) to stop being drawn to temporarily. Information on this seems sparse, though it's likely i'm not looking in the right places.
I could tie in some custom drawn XNA ScrollBars and set ShortcutsEnabled on the .NET TextBox's to false, but i would rather fix the root of this problem if possible.
Thanks in advance.
XNA works by having a game loop. WinForms and native c++ Windows GUI apps work by having a message pump. Sounds like you have fused the two somehow.
Perhaps you need to call the base Game.Update() somehow from within your forms's Control.WndProc
I used this code from the code project in order to display a .png image (with transparency). At line 87 I tried to add a label in which I succeeded but somehow It won't appear on the form. I tried Refresh, Invalidate but none of them worked. Maybe someone can point me into the right direction.
I think, since you're using UpdateLayeredWindow the "normal" painting mechanism is disabled, i.e. no WM_PAINT messages are sent to the window, and the WinForms library has no chance to render the Label Controls.
I found this article about using layered windows on MSDN stating:
Note that when using UpdateLayeredWindow the application doesn't need to respond to WM_PAINT or other painting messages, because it has already provided the visual representation for the window and the system will take care of storing that image, composing it, and rendering it on the screen. UpdateLayeredWindow is quite powerful, but it often requires modifying the way an existing Win32 application draws.
So I'm afraid that WinForms isn't able to work together with your approach. Even if it would, you would likely get unpleasant results since "real" transparency is not easily done with winforms (i.e. the labels wouldn't show up transparently but would be drawn the parent forms background color)
I am doing a UI automation for a WPF application using the Microsoft UI Automation library and it works well.
However my app has four screens in a TabControl. Even when I click the tab item through code its child control tree isnt populated. The only control I can see is the "thumb" Control. Same happens when I see the control tree with UISpy.
However if the window is clicked then all the controls appear. As a Workaround I am simulating a mouseclick through code and it works. I wanted to know if there is some better way of doing it.
I ran into a problem similar to this. What was happening was some data was being retrieved on threads and the controls were not generated at the point automation peers were generated. I would suggest if you have access to the code base for the application you are attempting to automate looking into whether threading is being used. In my specific case it was because BeginInvokes were used to retrieve the data, I switched them to Invokes and it worked fine.
Also from what I could tell the reason the controls were being show on mouse over was because the tool tip generated a popup and caused the automation peers to be updated.
Why don't you click the control using mouse events if that is what works.
(Now, if you still are having that problem..)
How to simulate Mouse Click in C#?
I have a form that contains a lot of runtime generated controls (image, button, panel,...), about 100 controls (I'm making a card matching game so there is a lot of controls in the form).
I place the generating code into the constructor and each time the app starts, it took about 3-5s to load all the controls completely.
If I bring another window on top and then back to my app, the controls will be redrawn again.
How can I prevent the controls from being redrawn? If you don't mind, please give me a simple example in C#.
Any help is appreciated!
I found this article that explains how to do this in .NET by calling the WIN API SET_MESSAGE function to set the WM_SETREDRAW flag for the control you do not want updated. Although you can stop certain controls from updating, are you sure you can't approach this issue by reducing the number of controls on the page? 100 Controls seems like a lot and may be an indication that you need to have multiple views.
Enjoy!
My suggestion is to use the form as a drawing surface and draw your card bitmaps directly onto the form. Its not hard to do.
You can add a handler to the form Paint event which will give you parameters with a Graphics object. Use graphics.DrawImageUnscaled to draw each card at the location you want.
This will make the app much much faster.
Preventing a control from redrawing is fairly pointless. You'll get a hole where a control was supposed to appear, your user won't have any use for that hole.
It redraws slowly simply because you have too many controls. You can only get it to redraw faster by using less controls. Or by using controls that can display multiple items in one window, like ListBox, ListView, TreeView, DataGridView.
Note that your specific issue is fixed in Vista and Windows 7. The Aero theme uses off-screen buffering for windows. Which means that windows don't need to repaint themselves anymore when they are obscured by another window. You will however still get slow redraws when the user minimizes the window and restores it.
You might want to consider using a single data table control. A ListView (or something like ObjectListView) may be a good option.
If your data isn't really a list/table, you should split the controls into separate tab pages, which would improve both performance and usability.