Jan 10, 2012 at 6:44 AM
Edited Jan 10, 2012 at 11: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.