I'm having the following code to set the width of the first panel to the width I need (for some reason I need to divide the expectedWith by two to get the actual width to be my expectedWith - don't know why).
splitContainer1.SplitterDistance = expectedWith / 2;
The next thing I need is that the first panel is fixed, means that if you resize the window, only the second panel gets larger and the first stays in size. To achieve this I use the following line:
splitContainer1.FixedPanel = FixedPanel.Panel1;
Problem now: it seems that the FixedPanel-property completly ignores the size of the first panel. It doesn't matter which value I set the SplitterDistance-property to if I used the FixedPanel-line. It is always the same. It doesn't even matter if I set SplitterDistance in the form designer.
Is there a solution to this?
I can answer my own question. This only happens if the content of the appropriate panel is using DockStyle.Fill in its Dock-property. The solution is to set the DockStyle.Fill value right after setting FixedPanel. This was also responsible for the "divide by two"-behaviour explained in the question.
Thanks to John Willemse.
I ran into this same problem, and was tempted to use the original poster's advice and just divide the desired SplitterDistance by two, as it always seemed to be (nearly but not exactly) twice the width that I asked for.
I tried changing the DockStyle of the children of the two panels to None before setting the SplitterDistance, but in my case it did not have any impact on the problem.
I solved the problem by changing when the SplitterDistance gets set. Originally I was setting the SplitterDistance on the panel before calling Form.Show(). Setting the SplitterDistance after the form is shown seemed to cure it.
Since you only want a fixed first panel and a dynamic second one, couldn't you use a TableLayoutPanel instead of a SplitContainer?
The DockStyle.None is a step in the right direction. But it needs 3-6 iterations (shaking the Splitter), until the Panel-Window has the expected dimensions. Strange!
I've figured this out. I needed to have a page open and load the splitter positions from the registry but was very frustrated with the way the watch I set up showed that it kept going back to the design time setting of the control.
To fix it all you do is change the property of "FixedPanel" from "None" to panel1 or panel2. Which is up to you. it only really comes into play when the minimum setting is not small enough and/ or when you have a splitcontainer within another sizable container. the fixed panel stays fixed then. Both panels can be resized as you choose using a mouse though so the word fixed is a little ambiguous in that regard.
so take the design time control. drop it on the form. resize it to fit your requirement and anchor it as necessary. nothing else except making one of the panels fixed. There is a property called "IsSplitterFixed" don't touch it, it's one of the reasons this control becomes unstable and must stay false, the panel.minsize properties should be set at design time based on requirements and you will always have to take cognisance of their values.
live happily ever after!
Related
How to run or adjust Windows application efficiently in any screen resolution in C# 4.0?
I have done it in 1600 x 1200 resolution but if I try in lower resolutions only some part of the forms are visible.
How to solve this problem? I have searched a lot and got to know about Anchor & Dock will be useful but also to came to know that these should be used from the beginning of designing but I have completed my application while this resolution is now causing the problem when I install the application in any system
The quick and dirty method of making sure your controls remain visible would be to place a Panel on the form, set Dock = Fill and AutoScroll = True, then place every other control in your form inside it. Your controls won't get cut off, but your program won't win any awards for asthetics. If the program is brand new, that's really not the way you want to start things off.
You could redesign it to make use of Anchors and Docking, as you mentioned. You could also place items such as a row of Button controls or a series of TextBox controls in a FlowLayoutPanel, which will take care of repositioning them as you resize the form.
But if adjusting for screen resolutions is important to you, a better way would have been to use WPF from the start. Controls are automatically resized and repositioned as needed, based on their container control.
The real question should be:
How do I want the controls to resize themselves with their parent?
The answer is that you need to specify anchors. Anchors are used to tell your controls how they should react on resize, and what the concerns should be.
Lets say you have a form with two [Cancel] and [OK] buttons. They are usually seen fit at the bottom right of your window. But the default Anchor property is set to Top, Left, so on your form's resize, they stick to the Top, Left corner where they belong according to the default settings. This won't be any trouble if your maximize your form, thus you'll have your button probably in the middle of the screen. But at least, you will see every controls adequately.
But what if resize your form smaller and smaller? Do you still want them to stick at the Top, Left, or Bottom, Right would be more useful? My guess is that you should set the Anchor property to Bottom, Right, for those two.
This might come in handy to have different Anchor property settings depending on how you want your control to react to your form resize. Let's take three TextBox controls aligned horizontally with each other. Perhaps your longer field will be your object Description property located on horizontal-center of your form. Then, when you risize, you have to think what would make more sense on resize. If it is to make it longer on resize in order to fill your form width with all your control, then perhaps you want the DescriptionTextBox to get wider and wider, and the contraray should also be true, on form's resize, you probably want this field to be resized smaller too. Then, to make this happen, you have to set the Anchor property to Left, Right, so that the edge of your DescriptionTextBox control remains at the same very distance of your form's edge at any time.
Another thing is of concern in case of resizing to smaller window, is its MinimumSize property. One shall agree that there is use to have a form of size 34x34 pixels. So, setting your MinimumSize property to a certain size which makes sens for the form to exist, you will avoid display glitches of controls getting one over another.
For more details on the Anchor property: Control.Anchor Property
For more details on the MinimumSize property: Control.MinimumSize Property
i'm currently modifying an existing C# WinForm project. I try to arrange some controls inside a GroupBox. However on runtime, they seem to be aligned differently and the Groupbox has a lot more space. Is there some option checked or is this the standard behavior? Any hints are highly appreciated! Thanks!
Here is what it looks like, as you can see there is no way except trial and error to arrange the checkboxes. On runtime there is easily enough space to have four colums in one row, in designer i can hardly fit three without having them overlap.
To prevent the groupbox to resize according to its content, you should make GroupBox.AutoSize to false.
GroupBox groupBox = new GroupBox();
groupBox.AutoSize= false;
check to Size property, and check if someone change it, for the checkbox Location to stay the same in different sizes of the form use anchor property and set it to left or left top.
it's basically must be the size, if the autoSize is off. check what's the starting size, and the size after the form is shown. it shouldn't be the same, but if it is, you can set it to smaller
Check the Anchor property on the checkboxes. Looks like some of them might be anchored to the right.
Not sure it applies to these checkboxes, but AutoScaleMode can impact the scaling of a form. Set to None to ensure it doens't get scaled.
I'm designing a UI in Visual Studio 2010, and I've come across a slight problem. I'm fairly new to XAML and this method of design, so this might be a rookie mistake. I've looked around but can't seem to find reference to a similar problem.
Basically, I have a grid with 2 rows, one of which contains a stackpanel and 5 columns. The stackpanel sits behind the columns and is used to paint the background of the entire row. When I add a background colour to the other row, I get an annoying line at the top of the stackpanel which just looks out of place. I've tried several things (showGridLines = false, transparent borders etc) but cannot seem to get rid of it. The best way to show it is through an image:
See http://img227.imageshack.us/img227/2220/tempym.jpg
One oddity I've noticed is that when I resize the window, at certain points the line disappears. Obviously this is not a solution (not least because it's going to be run full screen), but adds to the mystery of the line...
This is a trivial problem, but it is annoying me and will continue to do so until I can get rid of it, so any help would be appreciated. I've omitted the xaml for simplicity, but will post if required.
Based on the oddity you noticed, try setting SnapsToDevicePixels to true on the grid or window. Sounds like the borders are falling in between pixel boundaries and is being anti-aliased.
Or rather, if you're using .NET 4.0, use UseLayoutRounding instead.
I need to move controls around when the scrollbar's size change (System.Windows.Forms.SystemInformation.VerticalScrollBarWidth).
I'm creating a control with custom scrollbars that go over the normal ones. This implies creating a new UserControl (not inheriting a built-in control) and playing around with panels so as to hide the normal scrollbars.
The custom control must have one "outer" panel at the right size, this one containing an "inner" panel larger than the outer panel, so the scrollbars do not appear. How much larger depends on System.Windows.Forms.SystemInformation.VerticalScrollBarWidth and HorizontalScrollBarHeight as was already answered. But then I must know if that changes when my app is running, as improbable as it seems.
This question is related to:
How do I know the current width of system scrollbar?
I'm currently trying to achieve something similar.
I'm running Windows XP SP3, "Classic" style, and upon changing just the scrollbar width of the current design, my override of OnSystemColorsChanged() (in a class derived from Control) gets called four times.
Why it's four times I don't really know, I suspected it might be because there's four properties in there that seem to depend on that setting:
SystemInformation.HorizontalScrollBarArrowWidth
SystemInformation.HorizontalScrollBarHeight
SystemInformation.VerticalScrollBarArrowHeight
SystemInformation.VerticalScrollBarWidth
But all of these already hold the new value at time of the first call. So I'm not 100% sure what's going on here. But it looks like OnSystemColourChanged() should rather be called OnSystemInformationChanged().
Hope this helps ...
One must listen to Microsoft.Win32.SystemEvents.UserPreferenceChanged.
As takrl mentioned, OnSystemColorsChanged gets called, but only once for me (Windows7, Framework 3.5)
I have used Anchor property for some of my controls at design time.
but when I change the .Top property of those controls at run time, it seems that it is messing with the Anchor property and does not honor it anymore.
what is happening? how to fix?
I tried to reproduce the problem you describe, but was not able to match it exactly. The following example, however, may help you resolve the issue I suspect you are having.
(My employer blocks i.imgur.com, the image host for SO. If you have any problems viewing the screenshots, let me know.)
The following simple form contains a group box anchored on all four sides to its parent form.
When the button is clicked, the following code executes:
groupBox1.Top = 0;
Which results in the group box relocated like so:
Note, however, that anchoring is still honored:
I suspect you are looking for the effect that nothing except the top location of the control changes when you resize the control. Unfortunately, in this case, setting the Top property relocates the control rather than resize it.
You can accomplish resizing using the SetBounds() method, however. In the example below, I resize the anchored control, with a new top, using its existing bounds. Note that I don't take any measures to avoid illegal negative heights, which you probably should.
int newtop = 0; // the new top bound
groupBox1.SetBounds(
groupBox1.Left,
newtop,
groupBox1.Width,
groupBox1.Height + groupBox1.Top - newtop);
This results in a resized and relocated control that continues to honor its anchoring afterward: