In a WinForms application, I need to be able to interactively edit "hot" areas on top of an image, later to be used as a sort of image map.
I tried to rig together an UserControl with some floating rectangles (Microsoft.VisualBasic.PowerPacks ftw) on top of a PictureBox, but the result wasn't all that pretty, especially with flickering and refresh problems when the controls are moved.
Does anyone happen to know of an existing control that would help with defining areas on a canvas? I'm thinking that graphics applications, for example, need to deal with floating selections a lot, but I couldn't track down anything of use. Any ideas appreciated.
I have such a control ... with no designer support
There is one small bug (very intermittent) that I have not yet worked around, but it lies somewhere deep in the BCL.
If you would like a copy, drop me a mail (via www.sadeveloper.net), and I will send you a copy on two conditions.
standard immunity from any and all effects, no liability for any damages, incidental or otherwise ....
if you find the bug and fix it, you let me know how
MaLio
Sticking with your current solution for the moment. Your flickering could be a result of you not enabling double-buffering!
With double-buffering enabled, most (if not all) of your flickering should disappear.
In your InitializeComponent of both the custom control and the form:
this.SetStyle(ControlStyles.AllPaintingInWmPaint |
ControlStyles.UserPaint |
ControlStyles.DoubleBuffer,true);
Much more information available in this article.
Related
I need to rotate my custom control in Windows Form using C# without using third-party libraries.
Don't want to either rotate the text or image of control instead actually need to entirely rotate control.
From here:Is it possible to rotate a button control in WinForms?
5 up vote accepted
You can't rotate controls. That's simply not supported by the native API controls that WinForms uses.
And one might wonder why it even should be supported. What could you possibly be trying to do that you'd need to rotate a button control? It would be much easier to draw it in a different place with a different shape in the first place, rather than trying to rotate an existing control. (Do note that you can also resize and reposition a control at run-time, if that would fit your needs. Investigate the Size and Location properties.)
The only workaround is to draw the control's image to a bitmap, hide the control, and draw the bitmap onto the form in the location you want it to appear. Of course, that won't result in a control that the user can interact with. They won't be able to click an image of a button, because it's not a real button. If that's acceptable to you, you should probably be using an image in the first place, rather than a button.
It is possible if you can get control of the painting, but you have to do a lot of the work yourself. Basically it all occurs on painting. A good example demonstrating how to do it is the Dock Panel Suite for WinForms.
In the VS2005AutoHideStrip (found here), there is a GetTransformedRectangle method that uses a System.Drawing.Drawing2D.Matrix class to rotate a rectangle.
It also sets the Transform property on the Graphics class, which will apply transformations automatically when you ask for something to be painted.
I advise reviewing this code for examples, it does it to draw docked tab strips down the sides of the page as opposed to top / bottom.
Some controls like TextBox are funny in that they borrow heavily from low-level Win32 libraries in their painting / behaviour, I've no idea if it is possible to get enough control to rotate this.
It is not possible to rotate controls. This is not supported by WinForms' controls API.
As you are dealing with a custom control, try simply redrawing it to suit your purposes.
I am pretty sure you can not perform this in windows forms at least not easily. However you can perform this in WPF and then bring WPF to your windows Form if you are looking for cool designs or even special effects to your controls.
This is FAR more easily done in WPF. In Windows Form, it's a huage pain to pull off.
Hope this help
I have an idea for a personal project. And I know one way of accomplishing it in Windows Forms (which I no longer wish to use). Basically I could (in WinForms) just draw everything onto the screen (Form) and then when I need to switch views/states of the application, just redraw the new stuff in the old stuff's place.
But how can we have different states in WPF? Is there a "right" or "proper" way of doing this? Is something like this covered somewhere in the docs?
I'd like to do my own searching, but I have no idea what exactly to look for, and current attempts at finding the right information, so far have yielded no helpful (or even relevant) results.
Any help at all will be greatly appreciated. I am new to WPF, but have been making a lot of progress this past week!
Thank you!
P.S.:
I just thouhght of something. If the solution was to draw what is needed for one screen, and when it is time to display the next screen, just dispose of/hide everything and create/display the new stuff, then how would we get around this? Because we can't/shouldn't change XAML markup at runtime, can/should we? :/
Not sure how you drawn your views/states in WinForms (direct painting on a Graphics object?).
The closest to what you're describing is the VisualStateManager. You can use it to statically define several visual states inside a single XAML and transit between them (using a smooth animation if you want).
If what you've done was show different Forms with Show/ShowDialog(), then the equivalent would be to use different Windows and Show/Hide them.
If you just cleared/added Controls to your form, then you can do just the same in WPF. Most Controls in WPF have a Content or Children property instead of Control.Controls in Forms.
I don't know if I understand what you really want. But here are my thoughts:
You can use several Windows and Show/Hide them accordingly
You can use the Frame/Page functionality in WP (MSDN)
if you really need to you could load your XAML and remove the topmost content in your Window and replace it with the loaded content
You could use the VisualStateGroup functionality to change the appearance of your current window
I think you will be happy with the second solution
I know that when a drag/drop operation is completed, upon receiving a MouseUp or Esc key event, it returns an enum that indicates what happened (Move, Copy, None, etc.) My question is this: is there a way to send back status information to the form/control that initiated the drag event, while it is going on?
The use case is as follows (think Visual Studio-esque layout manager for all of this): I am writing a layout/window managing component that allows regions of the layout to be dragged around. I use a transparent form to paint a semi-transparent overlay that changes based on where the mouse is dragging over, a la the preview overlay that appears when dragging windows around in Visual Studio.
Another motivation is that the serialization process I describe is relatively resource intensive, and I'd prefer not to do it if the dragging is all going to occur within the same process/window. So, if there was a way to lazily serialize only when an actual "drop" in another window happens, that would probably make all the difference in usability.
What I want to do is enable dragging between different windows or even different instances of the application. I've already plumbed out the serialization code and everything, but the issue is that, when I drag a chunk of layout into another window, the first window doesn't have any way of knowing that the mouse is now over another instance of the application, which is more than capable of painting its own overlay. So, the original overlay hangs around like an idiot and my program looks like crap.
Is there any way for me to pass along some kind of callback or is there any message or property I can listen for/poll during a drag operation that will tell me if my mouse pointer is over a region that can accept its data? Please don't make me resort to listening for the CursorChanged event, I've already lost too much self respect using reflection to hack around weird wpf/winforms dragging interop bugs. If anyone could suggest a clean resolution for this problem I would be extremely grateful.
Additionally, if anyone could point me to any favorite sites which describe how to go about doing reeeeally funky things with drag and drop, it would be appreciated, as I've found there is quite a lack of really nitty gritty information available about dragging. Usual things like custom cursors and the like are okay, but I'm probably more interested in Win32 black arts and the like.
UPDATE:
I actually just found out about the GiveFeedback event a second ago, came back to my question, and there it was. Huge facepalm moment. However, since I've got you here, what about my second question: is there any way to lazily load the information only when it encounters a valid target? Could I somehow implement my own IDataObject or do things get marshaled righ when the mouse leaves the form? GiveFeedback provides me only with whether there's a valid target under the cursor, but doesn't let me change what data is being dragged...
ANOTHER UPDATE:
Is there any way to determine the source of a drag operation? That is, when my control receives a DragEnter message, how can I tell if the source of the drag is my own control or a foreign one? I know I can hackishly encode it by messing with the AllowedEffects property, but is there any more direct route?
Check out the GiveFeedback event (there's a nice article here) - that sounds to me to be exactly what you're after.
I'm building a control that comprises 15x15 = 225 buttons, and needs to be resizable. Because it's a grid, anchoring and docking won't work. I've tried both TableLayoutPanel as well as handling the resize event to manually place and size controls. In both cases, resizing is unacceptably slow. Suspend/Resume Layout in the resize function when I'm manually handling the layout doesn't help.
Is there something fundamental that I can change to speed things up, or is this just a limitation of the native controls? I understand I can build a custom control from scratch, handling the clicks and painting myself -- though I'd prefer to stick with the native controls if possible.
Edit
I know it's a lot of buttons. My question is a technical one; not one about UI design.
WinForms doesn't handle displaying this many controls at the same time unfortunately.
If I were in your situation I would first consider if I could split up the form in several pages. In many cases that would be easier to understand for the user as well.
But in your case that doesn't seem to be an option. Are you making something like a minesweeper style game? There you have a grid of buttons that all are clickable. In such a situation I would suggest you go for a custom owner drawn control where you consolidate all the buttons in one control. Don't build a composite control that contains 225 buttons - that won't help at all :-)
A final option could be to switch to WPF. WPF uses hardware accelerated rendering so it may be faster, but with so many controls not even that may help.
Facing an issue where in the user objects goes more that 10000 in windows app and the app crashes.
After much analysis we realized that we need to get rid of the panels that we use to align the controls and may be reduce the possibility of user objects reaching 10000.
Our App UI is dynamically generated driven by a configuration and it can vary. So all the UI generation is happening dynamically.
Any help would be much appreciated
This is an unfounded suggestion, but remember to make sure that unneeded Controls always detach themselves from events they are be subscribed to. A Control that's still subscribed to an event of an "active" (what's the right term?) object can't be cleaned up.
Just as a note, the Chrome development team hit this problem too, and the scroll bar arrows (among other things) weren't drawing anymore when some internal gdi limit was hit. It is quite possible to hit this limit in a complex enough gdi app.
You might want to do some research and see how they fixed it.
As an alternative, you could consider using a different platform, either gtk or wpf would do fine and they don't use gdi handles to draw.
from here,
If your program runs haywire, you will
find that it manages to create about
10,000 window manager objects and then
the system won't let it have any more.
Why stop at 10,000?
The first answer is "If you have to
ask, you're probably doing something
wrong." Programs shouldn't be creating
anywhere near ten thousands window
manager objects in the first place.
There is no need for that many handles. I think you need a new solution.
I'm guessing this from your question, but you're probably putting this large number of controls on a scrollable panel or a tab control with multiple tab pages, which means that most of these controls aren't actually visible to the user at any given point in time (because they couldn't possibly all be visible at once).
If you have all of these controls on a scrollable panel, one possible solution is to only load and display the controls that are on the visible portion as the user scrolls around in the panel. As the user scrolls, you would unload and dispose the controls that are no longer visible.
If you have all of these controls in a multi-page tab control, you can use a similar strategy and only load the controls on a tab page when that page is made visible (and unload the controls from the previous top-most tab page at the same time).
Another general strategy is to break up your one monster form into a large number of UserControls, and only show one of these UserControls at a time.