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.
Related
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've tried searching for the answer to this issue but I've been unlucky trying to find it.
From similar questions on here I've been able to make my transparent window receive mouse events, but then the other applications running behind it don't get any mouse events (Set the background of the window to #01000000 (mostly transparent)).
Or the alternative I've also achieved: the transparent window gets no mouse events and they are all passed through.
Is there a way to combine these 2 and have a transparent window that both interprets mouse events and passes them to whatever is behind it? My end goal would be to display a *ping* graphic on the transparent window (which is the same width/height of my desktop resolution) any time the mouse is clicked on the screen while I'm using other applications.
Further edit:
I have a Canvas in my WPF window. It has MouseLeftButtonDown as an element which calls a method in the behind-code. This method does not seem to get called when I use the solution that I linked, or when I simply set the Window and Canvas to Transparent or #00000000.
I think a better approach would be to use windows hook to catch global mouse events, and simply let your application discard mouse hit tests. As far as I know, Windows hook are not directly available in the .NET framework, but they are PInvokable.
Microsoft provides a pretty straightforward guide for this here.
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 am trying to make my application "flip" when the minimize button is pushed. By flipped, it should be kinda like a coin when flipped. It "flips" down into the taskbar. I am wondering how effects like this are accomplished in WinForms using C#. Can this be done or does something like this need to be done using DirectX?
You could P/Invoke AnimateWindow() to get effects like this. Visit pinvoke.net for the declarations you'll need. Beware that the novelty of this wears off very quickly, definitely make it a user-selectable option.
I don't know, but you can control (including animate) what's displayed within your application window. Doing what you want may therefore require you to animatedly move your window towards the taskbar, while flipping its contents.
This isn't something that WinForms natively supports. You could attempt to "simulate" a flipping window by shrinking the width of the form slowly to 0 and then growing another form at that location to the proper size that looks like the "back" of the window.
But there isn't anything like animations or transitions in winforms. You need to go to WPF for that.
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.