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
Related
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 have a form, originally developed to be used on XP, containing a .NET 4.0 ProgressBar control. It's part of a composite control, where I write some info on top of the bar using TextRenderer. (I didn't go for a label, because the transparency doesn't seem to work.)
I've now upgraded the OS to Windows 7, and it seems the whole look and feel of the controls has changed. The progressbar now has a kind of "swoosh" effect, a highlight that moves quickly from left to right. The problem is this animation is removing my rendered text. My app happens to update often, so the result is a blinking text on top of my status bar.
How can I fix this?
Any reason you have to write the text superimposed on the bar itself instead of underneath it, as everything else does? It sounds like it would be a lot easier to read the text if it were separate from the bar. That's certainly been my experience of progress bars as a user: keep any status messages away from the graphics.
EDIT: I've just checked, and if you don't call Application.EnableVisualStyles it uses the very old "big blue blocks" style, as far as I can tell. Personally I find this pretty ugly - I'd recommend that you stick with the nicer visual style, but move the text.
If you want to go all the way, you can remove calls to the Application.EnableVisualStyles method, which enables "colors, fonts, and other visual elements that form an operating system theme."
Visual Studio typically adds a call to this method in the Main method of a WinForms application.
Who fancies a challenge?
I'm currently working on the ControlTemplate for a chromeless Window which will be a part of a reusable theme assembly. I want the behaviors for moving, closing, minimizing and restoring to be implicit so I've written attached behaviors for this functionality which I've then included in the template.
Now,..I've come to resizing and I've come to a junction. For better or worse I'm handling the mouse move in the behavior and finding whether the cursor is inside the resizing 'zones'. I'm far enough to change the cursor appropriately but now I've gotten to actually resizing the window there are three options I've come across.
I could hand-ball the affair and adjust the Left & Top and Width & Height as needed. This is the simplest option and is easily achievable using attached behaviors but it seems like moderately heavy lifting and I understand that WPF will continue to render as the window is adjusted causing flickering,..which sucks.
The second option is to get a message hook and listen for WM_NCHITTEST and the like but the solutions I've found so far involve me sub-classing Window and I don't want to force consumers of the theme to use any controls that aren't framework provided.
The last option is to somehow draw a rectangle on the screen showing the are the Window will take up as the mouse is dragged and then resize on MouseUp,..which seems doable but it's not something I've done before so some pointers on that would be cool.
So,..what should I do? The Win32 route seems like my best option so far but I'd rather not if someone has a 'purer' solution that works. I'm happy to get suggestions with option 3 and anything right up to .Net 4 in case some dynamic magic might be possible.
Thanks in advance.
I implemented something in Windows Forms similar to DragMove but with boundaries set to 10 units of the margins of the primary screen.
When switching over to WPF I found this thread to be useful in achieving the same result.
However, since this is a post-move event, what happens is that if my window is dragged beyond the boundaries I set, it "jumps" back. I would like to avoid this effect as it looks terrible.
Is there a simple way to avoid the window to be moved outside a given area without using the LocationChanged event? I basically want to restrict the movement of the window before it happens.
These this are very hard to achieve with WPF because it does not expose the base Win32 functions and events like WinForms did. I had a project where I needed to to resize a window and I had to use PInvoke SetWindowPos to do this in a normal manner.
AddHook may help you, but this will still be quite difficult. See http://www.wpfmentor.com/2009/01/how-to-get-hwnd-and-hook-into-wndproc.html and http://msdn.microsoft.com/en-us/library/system.windows.interop.hwndsource.addhook.aspx for more information.
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.