8

There exists an EditorBrowsableAttribute in the System.ComponentModel namespace. The type EditorBrowsableState has following members:

  • Advanced
  • Always
  • Never

What could be the reason for this annoying attribute? Especially the state Never. It's hiding functionality and then when you find it you feel dirty using it. So if you are working at Microsoft and implemented this class tell me plz... :)

The only case I can imagine this attribute makes sense is when you want to mark something as obsolete and hide it from intellisense to focus better. But in all cases I encountered this attribute was used without an obsolete attribute. The most recent example i found is in wpf the Dispatcher.CheckAccess() method.

Diego Frehner
  • 2,396
  • 1
  • 28
  • 35

2 Answers2

10

IMO is an attribute devoted to libraries building, inside your VS solution (when dependencies are not external) Intellisense will simply ignore it. There are few useful use-cases.

Let's first see EditorBrowsableState.Advanced: with some languages (notably VB.NET) you can instruct IDE (actually Intellisense) to hide advanced members so you'll see only most common methods. Less noise for very beginners (you can enable full view when you master BCL little bit better and you're not intimated by huge number of obscure methods).

EditorBrowsableState.Never has other usages.

  • One is what you said (hide deprecated obsolete methods). An example is old Form.Closing event (hidden because replaced and extended by Form.FormClosing).
  • Another one is to hide errors and typos. If that attribute was applicable to, for example, Keys.HanguelMode then typo won't be visible (but present for compatibility).
  • It may also be useful if you need to expose few safe internal methods to other assemblies. You won't pollute your library interface with that methods (you may keep them documented and keep them as internal use only). It may be better than exposing all internal details through friend assemblies with InternalsVisibleToAttribute.
  • You may use it to hide potentially dangerous methods. You provide them because someone may need them but you want to stop people to use them, if possible.
Adriano Repetti
  • 65,416
  • 20
  • 137
  • 208
  • About the never: The first two points seem legitimate to me. The 3d and 4th are somewhat a grey zone, where i understand it can be practical. (but if usable why not show, and if not usable why just hide). What is your opinion on using that methods, as a developer not building the framework, just using it like most of us. Would you recommend not to use that methods? Or is it totally ok, if you know what you're doing. – Diego Frehner Dec 03 '14 at 09:09
  • 2
    If I'm working in a project where I'm the only developer (no matters if spanned across multiple solutions/modules) then I don't use it (and I **never** used EditorBrowsableState.Advanced). If I'm writing libraries used by someone else (also colleagues working on the same bigger project!) then yes, I use _Never_ pretty often (for all points I wrote, especially points 1 and 3). Actually because IMO people won't use what they don't see with Intellisense (who read docs?) and I may even not officially document them (as far as I'm only one to use them). – Adriano Repetti Dec 03 '14 at 09:15
  • 2
    @DiegoFrehner Yes, it's a weak form of protection and isolation but I prefer this InternalsVisibleToAttribute stuff. Imagine you're implementing a theoretical StringBuffer class and underlying char[] array is an implementation detail (detail you internally use for performance reasons). If, for example, you have separate [pluggable assemblies for culture specific text formatting](http://stackoverflow.com/a/23370462/1207195) you may need to use such detail to improve performance but you won't document it (or you'll document as _internal implementation detail_) and you would hide it _little bit_. – Adriano Repetti Dec 03 '14 at 09:25
0

EditorBrowsableState attribute is primarily meant for use in Visual Designers. EditorBrowsableState.Never is appropriate where some properties of a UI Widget or Custom Control being used in the designer surface is not relevant to or appropriate for the visual design aspects.

ash
  • 236
  • 1
  • 7