I have created a custom UserControl and then another control that is a subclass of this Usercontrol, but still has its own designer file behind it (the base control is just used for some base functionality... I don't need to 'design' anything on it and actually its height is set to 0).
Everything works as intended at run time, but at design time, it seems like whenever I open the child control in Design mode to work on it, Visual Studio keeps increasing the width on me, by perhaps a couple hundred pixels at a time (or possibly some factor). Before I know it, the thing is 10,000 plus pixels wide and then I have to reset the width in the designer just so it is manageable. This isn't an issue at run time, because the controls width gets set by a parent container it is put in, and the control is anchored to the parent. Its just a pain while designing the controls. Here's just little snippets to better explain what I've done:
public partial class BaseRow : UserControl
{
public BaseRow()
{
InitializeComponent();
...
}
}
Then I want to actually create controls that inherit from this BaseRow, but that I can edit in the designer. So, I go to Add -> UserControl. Then in the class code I change the default created code to inherit from my BaseRow (which inherits from UserControl) so it looks like this:
// changed the inheritance below from UserControl to BaseRow (which inherits from UserControl)
public partial class UnitRow : BaseRow
{
public UnitRow()
{
InitializeComponent();
}
}
I originally set the width of the objects to 400 in both the base class and the child class in the designer. The base Row sets its Anchor property in its constructor:
this.Anchor = AnchorStyles.Top | AnchorStyles.Left | AnchorStyles.Right;
because these controls will all go in a subclassed panel control that will control the width of rows that are added to it.
Everything works fine at run time. The actual width of these 'Row' controls I have created is set correctly and changes appropriately based on its parent subclassed panel control. But when I open the row controls in design mode at design time, the width is constantly getting longer and longer. Everytime the width equal 10,000 or more I manually change it back in the Properties window to a width of 400.
Its not causing any major issue. But it is a real pain. Anyone have any suggestions?
The workaround is to set anchor in the control's Load event handler:
private void BaseRow_Load(object sender, EventArgs e)
{
if ( !DesignMode )
{
this.Anchor = AnchorStyles.Top | AnchorStyles.Left | AnchorStyles.Right;
}
}
Now when you drag&drop control it won't set anchor at design time but will work in runtime.
Related
I have a form with a splitcontainer. One of the panels in the splitcontainer then loads a user control. This user control contains a combobox with the following properties changed from default:
DrowdownStyle=DrowDownList
FlatSyle=flat
Anchor=top,left,right
When the form and user control load, the combobox looks as expected:
However, if I resize the splitcontrol, it starts looking weird. If I increase the size of the panel that holds the control, this happens:
If i decrease the size of the splitter, it looks less weird, but still not how it is supposed to:
In either case, the combobox starts looking normal once I mouse over it.
Here is my code:
Main Form:
//Main form. Has a split container created from the toolbox
public partial class SampleForm:Form
{
public SampleForm()
{
InitializeComponent();
SampleControl cntrl = new SampleControl();
splitContainer1.Panel1.Controls.Add(cntrl);
splitContainer1.BorderStyle = BorderStyle.FixedSingle;
cntrl.Dock = DockStyle.Fill;
}
}
User Control:
//User control. Has a combobox created from toolbox. Options as described above
public partial class SampleControl : UserControl
{
public SampleControl()
{
InitializeComponent();
}
}
How can I fix this problem?
May be try to set dock to None . Also try to fix the margin for control
I know this is old, but was having the same problem and just in case someone finds themselves in the same predicament, answer below. Basically, create a new Class:
Imports System.Windows.Forms
Public Class MyComboBox
Inherits ComboBox
Protected Overrides Sub OnResize(e As EventArgs)
Me.Refresh()
End Sub
End Class
You can either drag this from your toolbox or add it in code. It will then auto redraw itself on resize of any parent controls.
Winforms is a bit like a sibling - flawed and deeply annoying sometimes - but you just gotta love it.
I'm experiencing some strange behavior. Let me try to explain, I stripped my code down to the bare minimum and I'm still having the problem. So first of all, I'm using VS2013 with .NET 4.0 and I'm on Windows 8.1.
So I have a custom UserControl with a TextBox that's being used through a ToolStripControlHost, if I focus on this textbox and hit TAB, it only cycles through the controls to the LEFT of this textbox. If I have it focused and hit SHIFT+TAB, it cycles through the buttons to the right of it.
So this is an example of my form. The textbox in the middle is a custom control. My code (as simplified as possible) looks like:
[ToolStripItemDesignerAvailability(ToolStripItemDesignerAvailability.ToolStrip | ToolStripItemDesignerAvailability.StatusStrip)]
public class ToolStripTestControl : ToolStripControlHost
{
public ToolStripTestControl() : this(new TestControl()) { }
public ToolStripTestControl(Control c) : base(c) { }
}
public class TestControl : UserControl
{
private TextBox _textBox = new TextBox();
public TestControl()
{
_textBox.Dock = DockStyle.Fill;
this.Controls.Add(_textBox);
}
protected override Size DefaultMinimumSize { get { return new Size(100, 22); } }
}
Simply creating a new WinForms (.NET4) project and following these steps will allow you to replicate the problem:
Add new class file and paste the code above.
Build
Add a ToolStrip to your form
On the ToolStrip add a Button, my custom control, and another Button (through the designer is how I've been doing it)
Run
Once running...
Focus in the custom control
Hit TAB a few times, it should only focus on controls to the left.
Hit SHIFT+TAB a few times and it will only focus to the right.
Does anyone know what the problem is - or how I can fix this? I've been tearing my hair out all day trying to fix this. I finally stripped my code down and I can't seem to get it to work. I even tried overriding much of the OnEnter/OnGotFocus functionality and doing it myself, but that became a nightmare.
Thanks!
Update1: So a few extra tid-bits.
If I change the custom control to inherit from TextBox instead of UserControl, tabbing/focus works as expected.
If I change it to be a Control instead of a UserControl the tabbing works fine, as well, however the focus never gets inside my inner TextBox - the focus seems to be lost (or presumably on the outer parent control but not being passed down to the inner TextBox).
I do see a MS Connect item added that describes this problem from 2009, but this link only seems to work if I'm NOT logged in to Microsoft Connect. Which means, I can't vote on it or comment... http://connect.microsoft.com/VisualStudio/feedback/details/472592/tab-cycling-through-controls-with-usercontrol-on-toolstrip-doesnt-perform-as-expected
The .NET 2.0 ToolStripItem classes have been a major bug factory. They are window-less controls, but reproducing the exact behavior of a Windows window isn't that easy. There is an enormous amount of code underneath, most of it internal so you can't tinker with it. And with quirks when they don't emulate the behavior of a window perfectly. You could call them "airspace" issues, pretty similar to the kind of problems that WPF has.
The airspace issue here is focus, entirely unambiguous for a true window but it needs to be faked for a ToolStripItem. It is actually the item's parent that has the focus, it needs to be emulated for the item. It is the transition that bytes, ToolStrip expects a window-based control to have a reliable Focus property.
Trouble is, your custom host doesn't. It is the inner control that has the focus. This could arguably be blamed on an omission in the ToolStripControlHost class. Probably. The trouble with emulating a window, there's never enough code :)
Anyhoo, fix your problem by adding this sliver of code to your host:
public override bool Focused {
get { return _textBox.Focused; }
}
m developing a sort of project which I needed a cool customizable interface, so I designed a 'parent-form' from which all childs would get 'stylized', according to XML customization options.
I added a TableLayoutPanel to draw borders and a Panel in the middle, where child forms would supposedly add their components and make their jobs.
The problem I face is, even though I set that 'content panel' to 'public', the designer wont let me add controls to it from the child forms.
Is there any different way I can make designable forms deriving from a 'customizable' superclass?
Edit: The parent class is public, every container containing the Content-Panel are also set to public.
I manually added to child's designer.cs a new Panel inside the parent's content pane, set it to DockStyle.Fill. When I came back to the Designer, it will now let me add components to child's content Panel.
A bit messy and I'm pretty sure there shall be another way around...
But I'll work along like this until i can figure out a better workaround.
I have added a new public Panel from code other than designer in the parent's class scope, Then in the parent constructor I added it to the TableLayoutPanel, configured docking and colspan from constructor code, below InitializeComponents() call and BAM!
public Panel contentPane = new Panel();
public Dialogo()
{
InitializeComponent();
Content.Controls.Add(contentPane);
contentPane.Dock = DockStyle.Fill;
// More code
}
So its a contentPane inside 'Content' which is another panel in the second line of the table ocupying 5 columns (so the table surrounds it and allows me to draw the borders around.
I don't know why, but having added the content-panel in code other than on the designer allowed me to directly add components to the panel from the Designer in child forms.
I've a base form class designed like that
At the bottom I put a docked-bottom panel and inside this panel I put two buttons. Also I set Anchor's property of these buttons to "Top, Right"
Also I've set Form's AutoScaleMode to None
On my application I inherited this base form and I don't know what is happening. My buttons go to the middle of my panel. If I set it again to the left and maybe rebuild my BaseForm it goes to the middle again.
I've seen this happen when controls in a base form have the protected modifier. That means that an inherited form can set the controls' properties (like Location) itself. BUt why it does it this way, I don't know.
When Winforms turned into an old lady, I stopped fighting her idiosyncrasies, just tried to work around them (as you do with old ladies). In your case I would use a FlowLayoutPanel in stead of a regular Panel and set its FlowDirection = FlowDirection.RightToLeft.
Have you tried checking to make sure in the panel_resize event there isn't any code that manually relocates buttons?
In some of the code I inherited, there is a lot of this :
panel_resize(object sender, EventArgs e)
{
int buttonWidth = btnSubmit.Width + btnCancel.Width + 5; // 5 is buffer between
int leftOffset = (panel.Width - buttonWidth ) / 2 ;
btnSubmit.Left = leftOffset;
btnCancel.Left = btnSubmit.Right + 5; // Buffer
}
This manually centers buttons during resize event ( you can do this differently, but that's what they did.) And means the design time looks different than the actual run time.
This is really simple.
I have a TableLayoutPanel that is populated with controls (just Labels, Buttons, and some Panels with buttons) based on a database query. When the data needs to be refreshed, I use TableLayoutPanel.Controls.Clear(). Unfortunately, this is a very slow operation. I would expect it to be faster than the code populating the table, but it is at least 3 or 4 times slower.
I definitively proved that the slowness is when executing Controls.Clear() by executing this as the single thing done to the TableLayoutPanel after a message box is displayed (then the procedure returns). The controls visibly disappear from the bottom up. When the recordset is used to repopulate the TableLayoutPanel, the speed of the controls appearing from top to bottom is almost faster than I can see.
I'm already doing TableLayoutPanel.SuspendLayout() and ResumeLayout().
Using this.DoubleBuffered = true on the form doesn't appear to do anything.
I could just Dispose the entire control and recreate it through code, but this is a big pain and makes having a nice form designer GUI pointless. I would have to dig into every property I've set on the control and create a line of code for it (though I guess I could get this out of the designer code itself, it still feels wrong).
Any ideas on how to do the job faster? I'm even open to using other methods besides a TableLayoutPanel... I just need the freedom to put multiple buttons per cell or barring that to be able to span columns in the table header.
Can C# at least freeze the whole form while it redraws and then paint all at once?
I've run into issues with slowness using TableLayoutPanels as well. Rather than setting the DoubleBuffered property on the form, the best solution I have found is to create a new class that inherits from TableLayoutPanel, and in that class' constructor, enable double-buffering:
public class DoubleBufferedTableLayoutPanel : TableLayoutPanel
{
public DoubleBufferedTableLayoutPanel()
{
DoubleBuffered = true;
}
}
Then, use the DoubleBufferedTableLayoutPanel wherever you would normally use a TableLayoutPanel.
This seems to work for my uses:
tableLayoutPanel.Visible = false;
tableLayoutPanel.Clear();
/* Add components to it */
tableLayoutPanel.Visible = true;
There is no need to subclass TableLayoutPanel as in Chris Ryan's answer. I had the same problem and solved it by setting the property through reflection:
typeof(TableLayoutPanel)
.GetProperty("DoubleBuffered",
System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Instance)
.SetValue(myTableLayoutPanel, true, null);
If i'm going to built up some dynamic gui i'm always going to do so in code. But at a starting point i just start with the designer on a dummy form and style each control the way i (or better the customer) like(s). Afterwards i take a look into the Designer.cs file and copy the necessary property settings out of it into some factory function like
private TextBox CreateTextBox(string name, /* maybe other parameters */)
{
var textBox = new TextBox();
textBox.Name = name;
//Other settings from given parameters...
//Further settings which are all the same for these kind of control
textBox.KeyDown += (sender, e) => {};
return textBox;
}
So i make sure that every control feels and looks the same on my GUI. This will be done on each level within my surface (starting with the small controls like TextBox and goes up to the containers like GroupBox or TableLayoutPanel.
In some cases this leads to a point where a factory function calls several other factory functions. If this is becoming true it's time to think about encapsulating these controls into a single UserControl, but as always it depends if this is needed or not.
From my side i can only encourage you to move your code out of the designer into a self-written function. At the beginning it is (as always) more work, but afterwards it is easier to make even bigger changes to the layout.