Edit controls in VS 2013 designer in a derived form

Question

3.00/5 (2 votes)

See more:

Hello everybody,

I'm using Visual Studio 2013 for a C# solution.
Now I derived Form2 from Form1 within one project. In Form1 is a TableLayoutPanel containing several buttons in a row. all controls are set to protected.

Why can I not edit the properties in the designer window?
It works fine for the other controls in the same panel that are derive from an even higher class.

Thank you very much in advance!

What I have tried:

I also tried public for all in between.
Further investigations have shown that the problem is TableLayoutPanel and not the buttons. They work fine when I drag them out of there.
Does this control have a malfunction in general? OR is it maybe even inteded to behave like this???

Posted 9-Jun-16 4:27am

herrstress

Updated 10-Jun-16 3:27am

v2

Add a Solution

Comments

Sergey Alexandrovich Kryukov 9-Jun-16 11:10am

Yes, you can. You did not show what you have tried, that's why I cannot see how can we help you.
Perhaps you have to read this:
What have you tried so far?

Anyway, programming by dragging all things in a designer is not a good working style; it is tedious manual land produced poorly maintainable code, if not worse, manual layout using absolute positioning. Designer should be minimally used, only to define basic layout structure.

—SA

Philippe Mori 10-Jun-16 9:06am

For simple UI and predefined controls, generated code is not that bad. And there is nothing wrong to use designer in that case as it is much faster and quite adequate for many scenarios.

However, deriving form is problematic if your base form have containers in it and you want to make some changes to them in derived classes.

Sergey Alexandrovich Kryukov 10-Jun-16 13:04pm

It depends how much is done in the adapter. It's not just to blame auto-generated code quality. If you do bad design, auto-generate code will be bad. Using designer is faster when you do basic things but slows down to unacceptable amount of tedious manual work easily. I saw a lot of such unacceptable-quality works. Say, some create 10 or more similar buttons and align each manually, instead of properly using Dock and Padding. This is the case where poor quality meets slow manual work.

A separate issue is naming. If everything not renamed with a refactoring engine to some semantically-sensitive words, the code becomes unreadable. Again, from the standpoint of code generation the names are just fine, it's just that they are not designed to be used permanently, need renaming.

And now, what do you think about the quality of event handlers? I never (except some pretty rare cases, only in XAML) use auto-generated handler, the quality of the code doesn't satisfy me from the very beginning...

—SA

Philippe Mori 10-Jun-16 9:39am

Does this control have a malfunction in general? OR is it maybe even intended to behave like this???
It is more a design limitation related to the way code is generated...

For simple controls, it is easy to change some properties in derived form and the only impact would be some properties set twice (once in base form and once in derived form).

For complex controls and in particular for containers, it is not obvious how to generate appropriate code as the code in derived class might need to be different depending on the code generated in base class.

2 solutions

Solution 2

As you can see form answers and comments, this is an area in which you need to write your own code or do it differently as that scenario is not properly supported by the designer.

Solution 1 explain the problem quite well. I will try to give some workaround that might help you.

Depending on the actual UI, there might be different solutions...

For buttons, using flow layout instead of table layout might works better. It might be simpler to have all buttons in the base form but hide those that do not applies if you have only a few buttons that are not visible for all derived forms.

Or the base form might have essentially an empty UI and protected implementation functions that would be used for code sharing purpose. That way, each form have there own UI that can be customized as desired.

Alternatively, you might use user controls to reuse some controls together. However, it might be harder to properly align controls in some cases like aligning an embedded button with one directly on the form.

Another solution would be to use code to modify derived forms. Thus you can use the designer to generate desired layout and then extract generated code for extra controls and move that code in derived classes. So the designer would be used only for initial design. Afterward, all modification would have to be done in code.

Posted 10-Jun-16 3:27am

Philippe Mori

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

BillWoodruff · Accepted Answer · 2016-06-09T13:31:00

edit ... after consulting my notes ...

MS clearly warns about using a Form that inherits from a Form with a TableLayoutPanel on it:

The TableLayoutPanel control does not support visual inheritance in the Windows Forms Designer. A TableLayoutPanel control in a derived class appears as "locked" at design time.

[^]. Now that's a bit strange, actually, because every Control defined in a Form that appears in an inheriting Form is going to appear "locked."

I suggest you read the above MS doc page carefully and note the number of cautions, and suggestions, regarding the use of the TableLayoutPanel.

I strongly suggest you don't attempt to use the TableLayoutPanel as a substitute for a "Grid." If you need a Grid, search on CodeProject, and examine some of the interesting custom Controls written about, like Philippe Piper's

What you observe is, unfortunately, just the "way things are" in Windows Forms. A Form/UserControl/Component that inherits from another locks the Controls it inherits ... by default.

I just gave a lengthy answer to a question on the C# forum about this issue; I think it may be helpful for you: [^]. It shows a technique for getting a reference to an inherited Control.

And, yes, there are specific problems with the TableLayoutPanel that I need to go back to my notes to describe more clearly. I will respond later today to your question. Specific problems with TableLayoutPanel include problems with AutoSize, and AutoScroll.

By the way, there's absolutely nothing "wrong," or "second class," about using the WinForms Designer to create/implement your user-interface design, and Visual Studio provides a powerful set of tools for helping you position, and align, Controls, snapping them to the "grid," etc.