Cannot resize controls

Question

This happens with windows forms, I drag a new control into de form and I can't resize it with the mouse, but the Properties tab is working. What can I do? It's strange because when I open another window project it works correctly is just with one project. Even more strange when I open a project in the same solution it works!

Thanks in advance for the help.

Answer 1

Does it happen with a single form or all forms in a project?  Is the form inherited from a base form class?  Can you replicate the issue by creating a new form in the same project? 

Does it happen on any control or just certain ones?  Some controls cannot be resized in all directions.  TextBox comes to mind as does Label.  You can also limit the size of a control via the MaximumSize/MinimumSize properties so if these are set then it won't resize either.  Finally the Locked property can be set to prevent resizing.

Michael Taylor - 9/3/2010
http://msmvps.com/blogs/p3net

 

Answer 2

It happens in all of the forms of the project, I can't resize any control, when I place the mouse over the small white dot to resize it, the pointer does not change to arrows.

All of the forms inherits from a base class. I added a form now that doesn't inherit from the base class and it works fine. Well I know know that the problem is the base class but it's strange because it was working fine. I'm using Infragistics controls in the base class, maybe is that.

Answer 3

The base class is the problem.  The WinForms designer only supports visual inheritance in the briefest of terms.  If you derive from a base form class then you cannot edit the controls on the base form via the designer.  You'll see a lock icon on the control to show you this.  This is actually in line with how master pages work in ASP.NET.  If you want to edit the base form then you have to open it instead.  Note that you can still programmatically change the base controls (if they are exposed) but you can't do so through the designer (in most cases). 

This is one reason why most people recommend against visual inheritance.  Most folks use user controls to implement inheritance.  You can create the base form however you want and then "child" forms are created as user controls nested inside the parent.  This works well in the designer.  Be aware though that non-visual inheritance is supported and commonly used.  So you can create a base form that has additional, such as logging or security, but don't include any controls.

Michael Taylor - 9/3/2010
http://msmvps.com/blogs/p3net

Answer 4

I use visual inheritance, in my base form I have some common functionality and a toolbar, in the child forms I add some other controls, but the strangest thing is that IT WAS WORKING! I was able to change the size of the controls in the child forms, but one day I started visual studio and I couldn't change the controls any more. Strange :S

Answer 5

Visual inheritance does not support the editing of controls in the base form.  This is a known limitation.  You have to switch to user controls to work around it.  The standard approach is to have a single main form and then host your "child forms" as user controls in the parent form. 

Michael Taylor - 9/6/2010
http://msmvps.com/blogs/p3net

Answer 6

I have the same problem.  I am not adding controls to the baseform. I am only adding controls to the inherited form. I am also in the situation where this has worked before but doesn't now.  I also have other inherited forms (inherited from a different base form) that work just fine.  It is obviously something in the base form, but I have no idea what to look for since there are no errors and no warnings.

Answer 7

As has been stated before visual inheritance doesn't really work well in VS for WinForms.  If you choose to go this path then you'll have to live with some of the problems.  A single parent form with user controls works better in pretty much every case.

As for your specific problem it should work provided you aren't dropping the control into a container that is owned by the parent form (ie. a panel).  If you do that then things might not work.  If you want to post some code then we can take a look.

Michael Taylor - 9/30/2010
http://msmvps.com/blogs/p3net

Answer 8

Just wondering what the addition of a constructor a.k.a the Public Sub New() plays into any of this.

Thanks in advance.

Answer 9

For controls and forms the default constructor should already exist.  It generally contains just a call to InitializeComponent (which is where the designer puts its code).  Without that call the designer generated code is skipped.  The ctor is called inside the designer when it needs to display your form.  The designer can't tell the difference between code you programmatically added in the ctor and changes you made via the designer or property window.  Therefore any changes you make in the ctor itself (like adding controls or setting additional control properties) will eventually be generated in the designer-generated code (basically the next time the designer needs to update the code).

If you need to modify control properties or add new controls to a form and you don't want them persisted by the designer then you need to either wrap the code in a if (!DesignMode) block or move the logic to the OnLoad method.  Either of these effectively hide the changes from the designer.  A great example of this is when you want to prepopulate a treeview with some nodes.  If you do that prepopulation in the ctor (just for test, for example) then the designer will eventually copy the node definitions to the generated file and you'll get duplicate entries.  Wrapping the code or moving it elsewhere solves the issue.

Michael Taylor - 10/14/2010
http://msmvps.com/blogs/p3net

Answer 10

Try changing the Window State of the base form to Normal. I had the same problem and I solved it this way. Build the base form assembly to reflect it in the inherited form.

 

Best regards,

LAZSer team

Answer 11

Also, set the AutoSize property False

---

Ramazan AKTOLU