Use EditorBrowsableAttribute for hidden members

Jan 10, 2012 at 5:44 AM
Edited Jan 10, 2012 at 10:39 AM

Some members, like ExcelApi.Application.Dummy22, are hidden in the COM type library. It might make sense to adorn these with the EditorBrowsableAttribute (with either Never or Advanced) (http://msdn.microsoft.com/en-us/library/system.componentmodel.editorbrowsableattribute.aspx) to allow the user to hide them from Intellisense.

At this level of hiding/showing types without changing what would actually compile, it might make sense to think about all the _... types, like _Workbook. Do we ever need these _XXX types? 

Another example: Workbook.AcceptLabelsInFormulas. In Excel 14 VBA this member is not displayed, and in the COM type library it is hidden. Maybe you can check whether it is hidden in all versions of the type library.

Some properties, like Workbook.CodeName, are readonly from VBA. They seem to have a corresponding _CodeName property which is read/write, but I think should also be marked EditorBrowsable(Never).

Another example is all the _Default properties. They should all be backed by a read property, like Value or Item, so they can also be hidden.

Basically all the _XXX interfaces and methods might be marked this way - they never appear in VBA. And to go one step further, you could apply this to the Object methods: GetHashCode, ToString etc.

 

The danger of implementing this is that you might get more support requests if some members are 'hidden' by the Intellisense. But I'd prefer at least some way to have the Intellisense list match more closely the VBA intellisense.

Coordinator
Jan 10, 2012 at 2:23 PM

its true what you say, the next source code preview has hidden members.
you want overwritten object methods(GetHashCode, ToString) with the hidden attribute?
hmm i want to be everbodys darling of course(interop and vba) and i'm not sure this a nice way for interop developers.

Jan 10, 2012 at 5:18 PM
Edited Jan 10, 2012 at 5:24 PM

What do you think would be the inconvenience to interop developers if the standard object methods (and perhaps those on COMObject) are marked as "Advanced"?

Anyway, I think the default configuration for the Visual Studio is to not hide Advanced member - but maybe that's something to check.

So it sounds right to me:

Methods like _Default and _CodeName should perhaps be marked [EditorBrowsable(Never)] and object methods like GetHashCode() and GetType() should perhaps be [EditorBrowsable(Advanced)].

Certainly this is not a serious issue for me - I just noticed it and was thinking how one could clean up the development experience a bit.

Jan 10, 2012 at 6:27 PM
Edited Jan 10, 2012 at 6:45 PM

If you do want to mark the Object members as Advanced, you'd only need to override and mark as [EditorBrowsable(Advanced)] them on COMObject itself. So this should not bloat the assemblies.

And some more info here: http://exdream.com/Blog/post/2010/01/15/How-to-keep-the-Intellisense-info-box-short-and-tidy.aspx.

Coordinator
Jan 11, 2012 at 12:08 AM

hey govert!
a new release preview is available.

changes:

- COMObject contains overwritten methods, GetHashCode, ToString, Equals
- Hidden members
- IEnumerable<COMObject> => IEnumerable<object>

*Sebastian

Jan 11, 2012 at 10:53 AM

Hi Sebastian,

It's looking better and better!

I suggest you also add an [EditorBrowsable(Advanced)] for an override of Object.GetType() in COMObject.

I suggest all members that start with an underscore  "_XXX" should be [EditorBrowsable(Advanced)]. I don't think they can be used from VBA, though some are marked as hidden in the TypeLib, others not. Also, Worksheet._CheckSpelling is marked hidden in the TypeLib, but not marked in the NetOffice. But maybe all the "_XXX" members should be Advanced.

I suggest all the get_XXX and set_XXX methods should be [EditorBrowsable(Never)] or even better, they should not be generated at all. Surely these all correspond to .NET properties, with compiler-defined get_XXX methods from the C# property definitions?

-Govert