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.
Related
What I need can probably be described as "reverse-anchor", "reverse-dock" or something like that (I have chosen to mention this just because "reverse-anchor" happened to be the first thing to come into my mind as a keyword candidate when searching for questions and answers that might already have been submitted discussing this subject, perhaps this will help people thinking a similar way to find this one in future). WinForms controls implement the Anchor property to set up adaptive resizing on containing control/form size change but I need the opposite - the form to resize adaptively to the controls.
A thing adding a minor bit of complexity to the task is that the controls meant to be added/removed/shown/hidden/enabled/disabled (and resized perhaps - this functionality is not really needed directly so far but I suspect it can turn to be required for compatibility with non-default Windows visual styles and themes that have potential to affect controls sizes unpredictably and can change at any moment of the app running) are not going to be the last ones on the form - a row of buttons will always be in between of the last control of the volatile group and the window lower border.
The actual task is to design a form that will display a collection of objects with a row of controls (a label, a text box and 0-2 buttons) corresponding each of them and it is strongly preferable to use just the very basic "common controls" avoiding grids, lists and stuff like that in this case (wrapping them in an additional container controls like panels is perfectly acceptable though, abstracting them in a separate "user control" can be considered too if this can really make the solution easier, more reliable or otherwise better, using hand-written code manipulating controls and form sizes is perfectly acceptable too (I can hardly expect a "set a magic property and it's done" kind of solution to exist for this task) but I haven't found a reliable algorithm so far (when to change what properties and what formulae to calculate new values with)).
The maximum capacity can be safely limited to something near 10 (or 20, perhaps, but not more - more would be just absolutely unreasonable to display on one form (provided scrolling is not an option)) so both ways are acceptable: to add/remove the controls in runtime or to put them on the form in the designer and just manipulate Visible and/or Enabled properties in the code. By the way I have found a problem with Visible - it gets switched off and back on by the framework internals before the form is rendered and other controls Anchor properties come in the game but I don't think it's a good idea to rely on this to happen always and the same way so just adjusting the form Size property on a control Visible property change does not feel really convenient).
What might be some good ideas relevant to implementing this behaviour?
PS: As far as I know this is a natural feature of WPF but I am to use WinForms to make the app runnable on Macs and, perhaps, other non-Windows platforms with help of Mono.
I'll tell you about some clues may help you:
1- correct to build your own Procedure for manipulating all the matter.
2- i advice to use a Wizard methodology (Next / Back buttons) so if the plate form is small like tablet or smart phone, so the mentioned procedure will decide how many Controls combinations (Label, text box, option button...) will be in each frame of that wizard and keep the remaining for Next button.
3- By the way if you will hide some controls use the original event fires to run the mentioned Procedure. (like a basic button to start the form so don't depend on visible / resize events).
4- Resize the size of each form of the wizard in the last part of the mentioned procedure.
If still a problem exists tell me and i hope i can help :-)
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 am learning multi threading in Win Forms using C# and according to sources the best way to achieve this is by invoking the main method from worker threads.
Now this all works good when heavy processing must be done and THEN the GUI is updated.
However I have a scenario where I need to programmatically add lots of controls inside a panel. This may go up to thousands (panel will be scrollable). Hence, since the controls are ultimately being added by the main thread, the program still hangs until this has been completed.
Is there any way around this? Or should I try and use some other control which doesn't require me to instantiate lots of controls simultaneously (as this is obviously a bit heavy).
Basically this panel contains a list together with an icon (depending on the state). Hence I am creating a label for every entry which I do not know if it the ideal way.
By the way I come from the web applications development department... Is there a control similar to a div in .NET? I looked at a rich text box but it doesn't seem to let you add an image in a straightforward way.
Thanks in advance.
You shouldn't have a good reason to add hundreds of controls, let alone thousands. It sounds like you need a custom control and you need to add items to it.
The ListBox or ListView control will work for a basic item but if you want lots of customizability you will have to reinvent the wheel yourself and draw everything manually. It's a lot of work if you need to handle multiselect, scrolling, keyboard shortcuts, etc.
This is the strength of using WPF instead of Winforms since you can easily use the existing ListBox logic and have free range to customize the appearance of the items and even how they are arranged.
WPF has the concept of a virtualizing panel which can perform well even with thousands of items since it doesn't create the UI objects until an item is scrolled to.
What is the difference between the winphone 7 Panorama and Pivot Controls? To me they seem very similar, apart from the slightly different visual appearance.
In which situations should one or the other be used?
There is a video on Channel 9 with Amy Alberts and Chad Roberts that talks about the differences between the Panorama and Pivot controls and when you should use each.
In my opinion, the Panorama control is for when you need to create a "hub"-type application (like the Games hub) that acts primarily as a jumping point and offers summary information for the rest of the application. The Pivot is used in much the same way that you would use a tab control on other platforms.
As said above, the Panorama control is really meant for rich Hub type look .. smooth multi-screen scrolling with Parallax effect, ideally including images in the views. The Pivot control is more for presenting slices of the related data to the user or categorizing the content .. the in-built emails & calendar are examples. Both controls are very suited for dynamic data-binding.
Jeff Blankenburg, one of the MSFT evangelists wrote two nice posts explaining their use:
http://www.jeffblankenburg.com/post/31-Days-of-Windows-Phone-7.aspx
Hope this helps!
I would use the Panorama control if the content of your application lends itself to being presented in a format where you think of the screen as being a window into a larger page...one that can loop back around to the beginning. Also, consider whether that content needs to support gestures, especially swipes, because those will cause conflicts between some action intended to take place in a control, for example a map with panning, and the "outer" Panorama control's behavior of scrolling.
I'm also reconsidering using the Pivot control. It has a more distinct division between sections of content than Panorama does and I like both the gesture swiping to switch between pivots and the animation. However, it has caused some tombstoning problems and with the advent of copy-and-paste there could be a conflict between the user trying to select content to copy and the triggering of the swipe gesture to switch pivots. Disabling the Pivot Control swipe gesture talks about a possible work-around, although I haven't tried it and see from the comments below that article that there may be some other issues.
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.