I created a winform application. The size of each screen is 1361, 768 in pixels. This worked great for larger screens and/or laptops. But now I have to move my application to 10inch screen tablets, which means my application does not fit.
I have never had to deal with this issue before, how can auto adjust each form size and adjust all of the controls and panels when viewing on smaller screens?
I am using VS 2012.
Making forms fully scalable in WinForms is possible, but it takes a bit of work. The good news is that most of this work is done at design-time, arranging the controls properly so that everything is done for you automatically by the framework. It's drudgery, but it isn't difficult. Rejoice that you don't have to write the scaling code by hand, form-by-form, like you did with VB 6.
There are four fundamental properties that you will need to acquaint yourself with:
Anchor
Dock
Margin
Padding
The last two should be quite familiar web developers who know CSS—they do the same thing here. Padding controls the inner margin around a control, while margin controls the outer margin. You will need to set these correctly to ensure that your controls can "breathe", because the automatic scaling code is just going to jam them up against one another.
The "standard" margins around a control in a Windows desktop application are approximately 12–15 pixels. You should make sure that you leave at least this much room. Then add additional margins/padding as you see fit to separate things. I keep these layout specifications bookmarked for reference. This is another good reference.
The next step is to instruct the layout manager how you want the controls to be arranged and resized. The key to this is to think in terms of container controls and child controls. The form itself is a container control, and you can set its child controls to either Anchor or Dock within its boundaries. One or more of those child controls can itself be a container control, and its child controls can be Anchored or Docked within its borders. The nesting is virtually unlimited, but for your own sanity and reasonable redraw performance, you'll want to keep it to a reasonable minimum.
A good way of doing this is to use the two provided invisible layout helpers, FlowLayoutPanel and TableLayoutPanel. Personally, I don't find the former very useful very often, at least not for standard Windows applications. But the TableLayoutPanel is invaluable.
Generally what I will do is fill my entire form with a TableLayoutPanel (margins = 0, dock = fill). Then I will add individual controls (or sometimes another nested TableLayoutPanel) to its cells. Those child controls will have their margins set appropriately, and will have either their Anchor or Dock properties set, depending on whether I want that control to have a fixed size or resize dynamically.
Before you get the hang of how these properties interact and how it all works, you'll probably need to play around with your layout a bit. Make a backup of your forms and then just dig in. Or, you might find it easier to start designing each form from scratch (you can still copy-and-paste individual controls in order to preserve their other properties). Eventually, it will all start making sense to you, and you'll be up and going in a jiffy.
The great thing is, once this is all set up, all you have to do is ensure that your form is resizable. Then, whether the user manually resizes it or uses the maximize/restore button, it'll automatically fill their screen size. This also works well for all DPI settings, which is another common Achilles' heel of WinForms devs.
Try to get the resolutions variables to adjust your screens, there is an answer to get these variables using the Screen class
Getting Screen Resolution
DevExpress has a great control call the Layout Control. This control helps to maintain consistent whitespace between controls as the form is resized. It does take a little study to use the control effectively but once you understand how to use this control the results are consistent and you are able to speed through form design.
Related
I'm developing the custom UI layout system for our custom SBO forms. I.e. catching form's resize event and arranging the controls according to our specific layout logic. The problem is that, apparently, SBO tries to arrange controls according to its (clunky and primitive) logic on every form resize first! My code handling the resize event and rearranging the items works, but there is a noticeable performance delay, as items are essentially re-positioned twice on each form resize - once by SBO itself, and then by my code.
Is there any way to stop SBO arranging controls on our custom forms during resize, so that they will be positioned only once by my code (in the resize event handler)?
This page by Boyum IT helps to explain what the resizing rules are.
There's additional information on this page
To summarize those pages, every form is split into 4 quadrants, which are effectively pinned to the corners of the form that they belong to.
That means that as you resize the form, these quadrants separate from each other, leaving large sections of space between them.
I don't believe that there's an easy way to prevent this behavior out of the box, but you can manually override it using the B1 UI API, by setting the LinkTo property of the Items to match the ID of one of the Items in the top left quadrant, which causes the given item to move with the same behavior as that of the item specified in LinkTo.
I made an application in Vb.net with winforms at a resolution of 1920x1080 not thinking it may need to run at a smaller resolution. When I run it at 1280x800 all the controls flows off the screen and doesn't fit even if I anchor/dock or use auto-sizing. I have tried putting my user controls in a panel and anchoring that too. Can you please give me advice on what I can do next, I'm out of ideas.
You could collapse or hide part of the form. Surely filling a 1080p panel is information overload. Also consider placing related controls in their own forms.
I just have it in my mind. And I can't explain it so here it goes.
A system that only uses 1 form?
It have a two panel, left and right.
The left is consist of buttons
Then the right is associated on the buttons and will change whether what button will be clicked.
Any ideas?
My preference is to do this via custom controls, rather than panels... but panels can work too.
There are a number of ways to do this:
Keep all of the controls layered on top of each other, and then set the Visible property to false for controls/panels you don't care about and to true for the Control/Panel that you do
Move the controls you don't care about out of the visible area
Remove/Add the Controls/Panels from Form's controls collection entirely
I think you can also get a TabControl to put the tabs along the left side, with some formatting that looks more like buttons, such that what you want will be handled without needing to write any code to switch layouts
Any of those can work. Whichever option you use, I have two recommendation for controlling layout and making the transitions smooth.
Call SuspendLayout() before making any changes, and then call ResumeLayout() when you're done. This will help avoid stuttering or a partially rendered form.
Look at the TableLayoutPanel Control. This control will allow you to arrange your top-level panels so that they can be resized with proportion. If you also then dock your individual panels, you can quickly build your program so that it resizes correctly.
You can have several panels, one on top of another. Change their visibility, depending on which one you need at a given moment.
Option #2 would be using a vertical tab control (or a tab strip - see another answer there).
Very weird situation going on with a FlowLayoutPanel...
I have been dynamically adding user controls to my panel. This user control has a height of 105. If I have my FlowLayoutPanelwidth to only show 1 "column" of controls, it will only display 296 of them. The rest of the controls are grayed out at the bottom of the flowlayoutpanel. If I widen the flp to allow 2 "columns" of controls, I can see 592 of them, with the remainder grayed out at the bottom. I have gone in and resized the user control to make it shorter in height, which works in some respects (i.e. it works when I have two columns, but not just 1), and can go forward with this work-around.
So, I guess my question is, why does the FlowLayoutPanel behave in this fashion? It seems (based on what I saw) that there is a limit to how much data the FLP will show at one time.
Your comment just reminded me that when you're adding many controls to any container it is a good idea to do this:
YourPanel.SuspendLayout();
// populate panel with controls
YourPanel.ResumeLayout(false);
This in effect stops the container (panel) from re-rendering itself every time you add a control until you're done adding controls. In the very least your panel creation will be smoother and faster. Not sure if this might fix your issue or avoid the need for a hack with PerformLayout.
If you look at your Form's designer file you will actually see this in action in the InitializeComponent function.
Is there an easy way to grow / zoom a VB.NET application and all controls within it to fill a larger screen resolution (or must I adjust each form element individually)?
NOTE: Adjusting the resolution back is not a permanent (or preferred) option in this case.
Please don't design your forms so they always fill the screen. Your customer has bought that nice expensive monitor to see more windows, not more of your form.
A well designed form is otherwise always resizable. Use the Anchor and Dock properties, TableLayoutPanel and FlowLayoutPanel to ensure that your controls move and size themselves properly. If your customer wants it big, she'll just click the Maximize button.