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.
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 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).
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.
I have an application which has a tabcontrol that contains two tabpages. I have a custom made usercontrol docked to fill up each of those tabs. When I resize my main form to the minimum size allowed one tab resizes accordingly while the other seems to overflow the area and a couple ui items slip out of access/view.
One usercontrol was quite literally copied from the other and renamed and fields adjusted. The usercontrol size is the same between the two. Within the usercontrols there is a datagridview and a large panel full of textboxes and they have identical sizes and identical anchoring properties and even the same location coordinates.
I'm struggling to find a difference between the two but I really would like the resize behavior to match between the two usercontrols. I was wondering if anyone would have ideas of other things to check I did not mention here?
This should like very odd behavior.
There are a few things that I can think of to check:
1) Double-check that the user control is actually on the tab page itself and not on a different control, such as the tab or a common tab area (not sure of the tab control you are using; some controls have a common area that is available to all tabs).
2) Verify that the Dock property is indeed set to fill on the "bad" usercontrol.
3) Verify that you are not resizing or changing the Dock property on the bad usercontrol in code.
Found a minimum size on one of the usercontrols and that was the cause of my issue. Don't know how I didn't see it earlier.
My main form has two panels, left docked and right docked. The right side panel has two child panels with top dock and bottom dock settings. The usercontrol is added to the right side top panel.
My usercontrol has a panel and a label. The panel is anchored on all 4 sides, the label is anchored on all except the bottom. At runtime I create this usercontrol and set it to dockstyle=fill and then I add it to my top right panel.
With everything set to "fill" I expect that when I add my usercontrol to the panel it will take on the appropriate width and height and pass that info to the child controls (labels) inside of my usercontrol.
My problem is that this stretching of the size does not happen when I create my objects during the Load event on my usercontrol. Even though initializecomponent has ran for the usercontrol the panel inside of it (4 corners anchored) has not taken the x/y values of the available space. As a result my usercontrol shows up about 50% of the width I want.
Lets say that instead of creating objects during usercontrol load that I instead start a timer and have the timer call my create routine when it raises the tick event. When I do things like this my objects are created with the full width/height that I expect. The only issue here is that this causes a delay in my interface.
Can someone help explain this behavior? My mainform is calling a "load gui" routine which is instantiating usercontrols, setting panel sizes, and then adding usercontrols to those panels. This particular user control is the last to load into the panels from that load gui routine so it does not make sense that the parent panel width/height would not be known yet. This is one of my first apps where I am purposely trying to use dockstyle=fill to keep things consistent across different main form sizes without writing all the extra size_changed code handlers. I'm sure this one is easy to work around once I know where the problem lies.
Thanks for any help provided!
this turned out to be a padding issue on the parent usercontrol. I also had to allow a bit of wiggle room to make sure that the controls didn't overflow the panel so I did a parent.width - 15 and that along with the padding made everything work much better.