We Keep Coding

Visual Inheritance seems buggy in Visual Studio 2019

I have a base form in my application, that I use the derive other forms from. This all works well, except that whenever I use the visual editor to change a derived form, the locations and sizes of widgets are b0rked.
Buttons move outside of the form, widgets become larger than the form, etc.
It only happens to widgets that are anchored right and bottom.
How can I prevent this?

design panel without parent form in Visual Studio

Anyone come up with a way that I can design a panel without a form?
On the surface usercontrol doesn't seem the way to go.
Background:
I come from a text editor world and VS is new to me. We did everything with panels instead of forms. So open for learning. Specifically have a base class panel (ExtendedPanel) that defines some basic controls: Cancel, Save, Save and Close. This ExtendedPanel then will be used for ClientExtendedPanel that is tied to a bindingsouce clientBindingSource. This is all tied to my entity framework model. So I will add, edit and delete sql datarows for my Client table. If no changes have happened by Save button will not be enabled. If I make a change but hit cancel it will warn me. I've done all this before but since I left that company I don't have access to the code base and they didn't use VS (text editor only)so it wasn't really transportable anyway.
All that background so I can ask: Is usercontrol the way to go, or is there something that will allow me to visually add controls to a panel like it is a form?

Yes, a UserControl provides a form-like canvas in the designer for you to add other controls (buttons, etc).
You can do this too by inheriting a panel and writing the code to add the buttons and wire their events, etc, but you won't get the designer support.

Make an Existing Windows Form Inheritable

I didn't realize at the time I create this particular application that I'd need to reuse some of the components - some Windows forms and a class or two.
Now that I've already created the fairly complex forms inside one project, what's the easiest way to transform those forms into inheritable forms that I can reuse in other projects? Once that's done I'd like to modify the existing project to use the newly created inheritable forms.
How can I accomplish this with as little pain as possible? I'm using C# in Visual Studio 2008.

You don't really have to do anything special to achieve this. Your form is already inheritable. On any new form, just make sure the first line looks like this:
public partial class frmMyChild : frmMyInheritableForm
instead of:
public partial class frmMyChild : Form
and make any methods that you need to access from the child either "public" or "protected".
Update: one additional trick is to set the Modifiers property of each control on your original form to Protected (instead of the default Private). In the designer for your child form that inherits from this form, you will then see all of the controls on the parent form, and you can move them and resize them as you see fit (this will not affect the original form's layout).
To access any parent method from the child form, you just call:
base.MyMethod();

Just declare an empty class that inherits from System.Windows.Forms.Form and then make your "huge" class inherit from that. Once that works, start moving, a small reusable piece at a time from your "huge" class to the parent class.

In your first project, add a new "Windows Forms Control Library" to your solution
Drag the windows/classes from the original project to the new one.
fix the errors.
At this point, you now have a Class Library which you can include in your second windows project.

Bear in mind that you don't need to design your forms to be inheritable in order to use them in other projects. Inheritable forms are a PITA, and in all but the simplest circumstances are more trouble than they're worth.
If you're simply looking to design your forms to be more portable, then the biggest thing that would be required is ensuring that you do NOT expose internal fields (Controls are included in that) outside of the form. If outside code (be it in the same or another project) needs to interact with the form in some visual or behavioral way, then you need to expose functions and properties that represent that functionality, rather than the control itself.
Apart from the design of the particular form, it would likely be helpful (if a somewhat time-consuming exercise) to move these common forms into a separate control library. While you can definitely add your .exe as a reference to another project, that's not ideal (and not entirely intuitive).

Using C# WinForms Designer on Panel instead of Form?

Warning: I'm new to GUI building in C# (come from a long history in Java with Swing and SWT.)
Using VS2008, When I create a new class, and extend System.Windows.Forms.Form, the WinForms Designer works really nicely. However; when I create a new class and extend System.Windows.Forms.Panel, the designer does not work nearly as elegantly - it simply shows some kind of abstract, list-type view of the components contained in the Panel (as opposed to showing the actual layout of the Controls in the Panel.)
Is there a way to get the Designer to work more nicely with a Panel?
Or is there some workaround so that I can build a Form with the designer, and then use it as if it were only a Panel?
What I'm really looking for is some UI 'element' I can build with the designer, and then dynamically (read: programmatically) add/remove that 'element' to a larger UI.

I think what you're looking for is a UserControl. You can inherit directly from that, and you should be able to use the designer to drag and drop stuff on it.
To make it even easier, you can just right click on your project and click Add -> User Control. That will create the .cs file for you as well as a partial .cs file for the designer generated code.

How to create a tree-view preferences dialog type of interface in C#?

I'm writing an application that is basically just a preferences dialog, much like the tree-view preferences dialog that Visual Studio itself uses. The function of the application is simply a pass-through for data from a serial device to a file. It performs many, many transformations on the data before writing it to the file, so the GUI for the application is simply all the settings that dictate what those transformations should be.
What's the best way to go about designing/coding a tree-view preferences dialog? The way I've been going about it is building the main window with a docked tree control on the left. Then I have been creating container controls that correspond to each node of the tree. When a node is selected, the app brings that node's corresponding container control to the front, moves it to the right position, and maximizes it in the main window. This seems really, really clunky while designing it. It basically means I have tons of container controls beyond the edge of the main window during design time that I have to keep scrolling the main window over to in order to work with them. I don't know if this totally makes sense the way I'm writing this, but maybe this visual for what I'm talking about will make more sense:
Basically I have to work with this huge form, with container controls all over the place, and then do a bunch of run-time reformatting to make it all work. This seems like a lot of extra work. Am I doing this in a totally stupid way? Is there some "obvious" easier way of doing this that I'm missing?

A tidier way is to create separate forms for each 'pane' and, in each form constructor, set
this.TopLevel = false;
this.FormBorderStyle = FormBorderStyle.None;
this.Dock = DockStyle.Fill;
That way, each of these forms can be laid out in its own designer, instantiated one or more times at runtime, and added to the empty area like a normal control.
Perhaps the main form could use a SplitContainer with a static TreeView in one panel, and space to add these forms in the other. Once they are added, they could be flipped through using Hide/Show or BringToFront/SendToBack methods.
SeparateForm f = new SeparateForm();
MainFormSplitContainer.Panel2.Controls.Add(f);
f.Show();

Greg Hurlman wrote:
Why not just show/hide the proper container when a node is selected in the grid? Have the containers all sized appropriately in the same spot, and hide all but the default, which would be preselected in the grid on load.
Unfortunately, that's what I'm trying to avoid. I'm looking for an easy way to handle the interface during design time, with minimal reformatting code needed to get it working during run time.
I like Duncan's answer because it means the design of each node's interface can be kept completely separate. This means I don't get overlap on the snapping guidelines and other design time advantages.

I would probably create several panel classes based on a base class inheriting CustomControl. These controls would then have methods like Save/Load and stuff like that. If so I can design each of these panels separately.
I have used a Wizard control that in design mode, handled several pages, so that one could click next in the designer and design all the pages at once through the designer. Though this had several disadvantages when connecting code to the controls, it probably means that you could have a similar setup by building some designer classes. I have never myself written any designer classes in VS, so I can't say how to or if its worth it :-)
I'm a little curious of how you intend to handle the load/save of values to/from the controls? There must be a lot of code in one class if all your pages are in one big Form?
And yet another way would of course be to generate the gui code as each page is requested, using info about what type of settings there are.