[RESOLVED] General syntax question: hiding properties

Hello everyone.

I have a (pretty large, 1000 lines or so) class with a lot of properties, both regular, overridden and overloaded properties. I currently add this in front of the property to hide it from the designer:

Code:

---

<Browsable(False), DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)> _

---

This is all great, but it adds quite some lines to my project. How can I specify, for my class or project, that it should add the above settings to all?
Or even better: set the above settings for a block of code instead of a single property.

I don't believe what you want here is possible.

Kind of expected that answer... :o

Ow well time to add that code to the toolbox. :D

Are you trying to use that as a single line to apply to all properties? Is that to reduce the number of lines in your code files, or is that to reduce the amount of copying and pasting that you have to do?

EDIT: It's not that I have an answer, I'm just trying to be clear on the reasoning here. Are you trying to reduce clutter or time?

Both, really. :bigyello:

Background information:

Quote:

---

1. I am making an extended RichTextBox control
2. This control has a lot of new properties, like:
* SelectionLine (Start/Length/Lead/Trail/End)
* Lines property to reduce regeneration of MyBase.Lines too much
* SelectionWord (Start/End)
* LineStart, LineEnd
* Conversion from startindex to the above
* Highlight (in progress)
* Coloring, Colored
* History
* Information: Template, SelectionInfo

---

And some other overloaded/overridden/new functions like undo and canundo.

It does not take too much time, but I just don't like having that header in every single one of those properties.

here's how to remove all properties. note though, there are some properties you can't remove.
+ you need to add a reference to System.Design:

vb Code:

Imports System.Windows.Forms.Design
 
Public Class MyControlDesigner
    Inherits ControlDesigner
 
    Protected Overrides Sub PreFilterProperties(ByVal properties As System.Collections.IDictionary)
        MyBase.PreFilterProperties(properties)
        Dim pi As List(Of DictionaryEntry) = properties.Cast(Of DictionaryEntry).ToList
        Dim keep() As String = {"BackColor", "Location", "Name", "Size", "TabIndex"}
        For x As Integer = pi.Count - 1 To 0 Step -1
            If Not keep.Contains(pi(x).Key.ToString.Trim) Then
                properties.Remove(pi(x).Key.ToString.Trim)
            End If
        Next
    End Sub
 
End Class

vb Code:

Imports System.ComponentModel
 
<DesignerAttribute(GetType(MyControlDesigner))> _
Public Class UserControl1
 
    Private Sub UserControl1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
 
    End Sub
End Class

Nice code! :)

Never knew it was possible to use class names inside the <> codes. I'll definately look into it and make it hide all properties that start with "SelectionLine" :thumb:

EDIT

Aw an error :/

Quote:

---

ControlDesigner is not defined

---

Code:

---

Imports System.Windows.Forms.Design

Public Class MyControlDesigner
    Inherits ControlDesigner
    Protected Overrides Sub PreFilterProperties(ByVal properties As System.Collections.IDictionary)
        MyBase.PreFilterProperties(properties)
        Dim pi As List(Of DictionaryEntry) = properties.Cast(Of DictionaryEntry).ToList
        Dim keep() As String = {"BackColor", "Location", "Name", "Size", "TabIndex"}
        For x As Integer = pi.Count - 1 To 0 Step -1
            If Not keep.Contains(pi(x).Key.ToString.Trim) Then
                properties.Remove(pi(x).Key.ToString.Trim)
            End If
        Next
    End Sub
End Class

---

System.Design does not exist.

If it is the FrameWork version that is bugging then this is not a good solution, since I want to keep the FrameWork requirement <= 2.0

<= 2????

That's stepping pretty far back. Are you really including 1.0 and 1.1? The biggest difference between the versions seemed to be the step from those up to 2.

You should have specified, I thought you basically wanted to see if you could take any attribute and propagate it down on all the members.

Being compatible with <= 2.0 isn't possible without writing two separate applications.

.NET 1.0 and 1.1 run on compatible CLR versions. .NET 2.0 is a new CLR. That means while 1.0 and 1.1 applications can run on the 1.1 CLR, there is no way to run a 1.1 application on the 2.0 CLR; you have to install 2.0. There is no way to build a 1.1 application that will work on the 2.0 CLR. If there is and I've missed it, it's not safe because this segmentation was made by Microsoft to indicate they were making breaking behavioral changes that would be impractical to enumerate.

Assuming you mean you're writing the application for .NET 1.x, the answer is simple: don't. It's ancient and it was the first attempt at the CLR. It is the worst version of the CLR; lack of Generics means you're either writing tons of "strongly typed" collection classes or doing tons of performance-eating boxing/unboxing or both. Just don't.

As far as I can tell ControlDesigner existed in .NET 1.1 in System.Design.dll. If you're targetting 1.0, you should *really* think long and hard if you want to go down that road. The *only* use case is if you want to support Windows 2000, which is pretty far-fetched.

If you're writing for .NET 2.0, the class is there, but you'd be getting some other errors due to some methods that rely on 3.0 or 3.5; it's easy enough to fix those. You've done something wrong if it's complaining about ControlDesigner *and* you don't have System.Design.dll.

Perhaps you're worried about using a .NET version that's already installed? If that's the case, the solution is easy: Windows is not a .NET Framework delivery platform. I don't think any flavor of Windows comes with .NET 1.x. By default, XP comes with nothing. Vista comes with 2.0. Win7 comes with 3.5. But this is by *default*. System administrators might remove them. So you cannot assume any version is present. It's always best to include instructions for installing the appropriate framework version with your application.

Also: I would be strongly suspicious of a 1000+ line class with enough properties you want to hide that it is tedious to do so. Good classes are usually small. Good classes don't have properties that shouldn't be set. It is often the case that when what you are doing is hard, you are doing something wrong. Perhaps you should reconsider your design; is it really worth all the effort?

Quote:

---

Originally Posted by Sitten Spynne

Good classes don't have properties that shouldn't be set.

---

Not true, especially when it comes to custom controls. A lot of the time you are hiding members that no longer apply to your version of the control. One example is the panel that gets used for a SplitContainer. Do you think they re-wrote the entire Panel class just to avoid properties that should no longer be set? I.e. Location, Size etc... No, they filtered the properties out (in a similar way to how paul is doing it) and they hide them in the IDE as well. And while you can still set these properties the implementation will basically ignore it.

Quote:

---

Originally Posted by bergerkiller

System.Design does not exist.

If it is the FrameWork version that is bugging then this is not a good solution, since I want to keep the FrameWork requirement <= 2.0

---

i wrote it in .net 3.5
back to the tedious way then:D

i just tested it in vb2005.
it works with minor modifications.
as i said in post #6, you need to add a reference to System.Design

Ow wait yeah, was importing it my bad. :blush:
Works now

Quote:

---

Originally Posted by ForumAccount

Not true, especially when it comes to custom controls. A lot of the time you are hiding members that no longer apply to your version of the control. One example is the panel that gets used for a SplitContainer. Do you think they re-wrote the entire Panel class just to avoid properties that should no longer be set? I.e. Location, Size etc... No, they filtered the properties out (in a similar way to how paul is doing it) and they hide them in the IDE as well. And while you can still set these properties the implementation will basically ignore it.

---

Emphasis on good classes. I'm a bit of a purist and MS didn't do a really good job with the WinForms hierarchy, though they may have had ease of discovery in mind more than purity of design. It's a tough balance and I won't claim I'm right, but I do take a different point of view.

The L in SOLID is the Liskov Substitution Principle. It states you should be able to substitute any derived class for another without noticing a difference. WinForms breaks this hard and you don't need to look far to find problems. For example, this method has a subtle flaw:

Code:

---

Public Sub AddControl(ByVal parent As Control, ByVal newChild As Control)
    parent.Controls.Add(newChild)
End Sub

---

Everything looks fine and dandy until you screw up and accidentally try to add a MainMenu to a form. These are both a "top-level" control and you can't add a top-level control to another top-level control. So instead you have to write this:

Code:

---

If Not newChild.GetTopLevel() Then
    parent.Controls.Add(newChild)
    ...

---

In a good hierarchy, Control would have derived types TopLevelControl and ChildControl. Then the method becomes:

Code:

---

Public Sub AddControl(ByVal parent As Control, ByVal newChild As ChildControl)

---

Now it's easier and more clear that you can only add non-top-level controls, and if you want to ask "What's a top-level control?" you can get an answer more easily.

Here's another tricky one. Every control has a Text property. But what's it do for Panel? Even worse, NumericUpDown looks and behaves like a text box, yet setting the Text property has no effect. It doesn't throw an error, you don't get the compiler warning you it shouldn't be done, it just looks like you've got a broken control until someone tells you for that one control you always use Value instead.

For that matter, why does Control have a Controls property? What does that make ContainerControl? Believe it or not, this code works and does what it says:

Code:

---

        Dim btn As New Button()
        btn.Dock = DockStyle.Fill

        Dim textbox As New TextBox()
        btn.Controls.Add(textbox)

        Me.Controls.Add(btn)

---

Why can a control that's not a container control be a container for other controls? :confused:

I'm not going to go through the effort to try and design a hierarchy that works better, but I believe if a class inherits a property that is invalid, your inheritance structure has issues. Sometimes fixing these issues leads to code that's a little more difficult to use because we don't have multiple inheritance. For example, one of the solutions I could propose might make setting an arbitrary control's text look like this:

Code:

---

DirectCast(someControl, ITextControl).Text = "Oh bother"

---

In some contexts, that makes sense. Programmers are supposed to be smart people, and we can't always write least-common-denominator code. On the other side of the coin, the more you have to think about the code you're writing the more likely you're going to make a mistake. Stalemate.

With WinForms' current structure there's places where a deep knowledge of each control is needed to understand how to use them. With an improved structure, you'd have the same problem. If you're writing a custom control you often do have to jump through these hoops to hide the invalid stuff because you have to play on the WinForms court. But if you're not subject to the whims of another designer, big classes with lots of invalid properties are a headache. "Big class" starts somewhere around 100 lines and gets smaller the more you get used to it. "Lots of invalid properties" starts at 2 and decreases to 1 as you use classes that make you check tons of state before doing something simple.

While there is validity in what you are saying, the amount of classes that would result from having said structure would probably increase 10 fold, and I don't know how much more practical it would make things.

Quote:

---

In a good hierarchy, Control would have derived types TopLevelControl and ChildControl.

---

Even if it did, the language doesn't support partial or selective inheritance. If you want to derive a type then you get it all. A lot of your points are not WinForms problems, they are language 'restrictive'. I'm putting that in quotes because I cannot decide whether it is actually a restriction.

Quote:

---

For that matter, why does Control have a Controls property? What does that make ContainerControl? Believe it or not, this code works and does what it says:

Code:

---

        Dim btn As New Button()
        btn.Dock = DockStyle.Fill

        Dim textbox As New TextBox()
        btn.Controls.Add(textbox)

        Me.Controls.Add(btn)

---

Why can a control that's not a container control be a container for other controls?

---

This isn't the greatest example only because how would you break apart controls that you think should be able to host other controls. Also some controls use that collection for internal use. As an example you used the Button class, what if that was a DataGridView? You know that a DataGridView inherits from Control but did you know that internally the DataGridView adds a HScrollBar and VScrollBar? Now in terms of a container control it doesn't qualify because you can't add controls to it (you can but you know what I mean), but it uses controls internally. So should the DataGridView inherit from a class that is some sort of Control derived class with an internal (protected) control collection?

I guess what I'm trying to say is that:

a) It would be extremely hard to separate that kind of functionality out of classes
b) The amount of classes that would increase from such a change would make programming more difficult (IMO)
c) The points raised aren't actually WinForms specific. Partial/Selective/Multiple inheritance isn't supported by this language so you could technically apply all of your points on the entire framework.

Before this goes down a different road:
What I mean is that my program should not require (ancient) users to download the .NET framework v4.0 while having 2.0. Some users don't have the Internet capacity to download 4.0. :rolleyes:

But what exactly happens between versions? Say I have v4.0 and make a program; does this mean the exported program NEVER works on v2.0? Even if the program only uses 2.0 available codes?

I could list out all of the information related to it but it's much easier to discuss the simple rule: If you want your program to work for a specific version of .NET, you should explicitly target that version. You can write an application in VS 2010 that targets .NET 2.0 and the compiler will not let you build if you use something that won't work in 2.0. VS 2010 can target 2.0, 3.0, 3.5, 4, and a few Silverlight versions. VS 2008 can target 2.0, 3.0, 3.5, and a couple of Silverlight versions. VS 2005 can only target 2.0, and I wouldn't touch an earlier version without hazard pay :p

If you want to make life difficult, you have to navigate all of the rules. You have to know things like "1.0 and 1.1 share a CLR, 2.0-3.5 share a different one but have different dependencies, 4.0 is different, but 4.0 is different in a different way and you can use this configuration file..." It's possible that a program compiled for 4.0 runs on 2.0 due to some technical details. It's possible that the program will run but apear to randomly crash for no reason when it hits a behavioral incompatibility. It's a major pain in the butt to support, and it's better to just follow the bolded rule than to be clever.

I'm an arrogant American, but the requirements for downloading the .NET Framework are getting more and more reasonable every year. Right now if you send your customer to Smallest Dot Net, it will likely recommend a download between 30 and 50 MB, which will get them the .NET 4 Client Profile or perhaps the full profile. Don't be misled by the 250MB+ distributable; that one includes the installer for .NET 4 for x86, x64, Itanium, and lots of other files that aren't needed but have to be included if you're going to provide a universal installer. If you really want to serve people that can't download a 30MB file, you'd serve them better by writing a native Windows application in C++. Even when I had a 33.6 modem I can clearly recall sitting through 30MB installs for applications that I really wanted, and in this case I bet the installer takes longer to run than the download.


@ForumAccount: I agree in many ways, which is why I pointed out the designers favored the more discoverable design over the more pure. The spots where I disagree aren't worth starting another thread over, other than to mention VB *can* have a simulacrum of Partial/Selective/Multiple inheritance via interfaces. People focus so much on class inheritance they don't seem to notice the benefits of interface inheritance. I have an example of a zoo simulator that makes a better case; perhaps one day there will be a thread appropriate for it. (I vaguely remember typing it out recently but I am too lazy to figure out if it was on this forum or another.)