CODEWITHSUNDEEP
c#excel-interopnamed-rangesindexed-propertiesresharper-9.2
B. Clay Shannon-B. Crow Raven
B. Clay Shannon-B. Crow Raven

Reputation: 10247

What does Resharper have against the commonly-used getRange() in Excel Interop?

Almost all of the example code online for C# Excel interop has stuff like this:

monthlyChartRange = _xlSheetChart.get_Range("A3", "C4");

Yet, Resharper turns up its nose at it and demands: "Use indexed property" If you accede to its wishes (and I love R#, so I always say, "As you wish"), it changes it to:

monthlyChartRange = _xlSheetChart.Range["A3", "B4"];

Why? How is Range better than get_Range? How is the former any more indexed than the latter?

Upvotes: 0

Views: 231

Answers (2)

user585968
user585968

Reputation:

Yet, Resharper turns up its nose at it and demands: "Use indexed property"

A bit of an intro - COM goes way back. You must bare in mind that COM is a binary protocol and that some COM-aware languages have no concept of properties.

COM indexed properties are generally defined like so:

[propget, id(DISPID_VALUE), helpstring("blah")]
HRESULT Item([in] long Index, [out, retval] BSTR* Item);

The dispatch ID is DISPID_VALUE which informs clients that this is the default property typically used for indexed properties. Notice how it is defined as a property get but interestingly it takes a parameter index. The notion of a property getter that takes an argument can be confusing to some programming languages as we shall see.

Fully COM-compliant Client Languages

A good COM-aware client language (such as VB6; VBA; .NET) will allow you to interact with the object like so:

string thing = myObject.Item[2];

These languages sees that this particular property is a propget however it takes and in parameter. The fact that it is marked as DISPID_VALUE is rather riveting because that tells COM clients that it is the default property. Putting two and two together, clients will realise that it must be a dandy indexed property so that they can use groovy square brackets.

It's important to realise that this is just sugar syntax. It's just a more convenient way to call the default indexed property. Behind the scenes, it will call the same COM property getter method as per un-compliant languages as shown below.

Not-so-COM-compliant Client Languages

Some programming languages (like Visual Objects 2.6), freak out (then again I freak out when I use VO) when they see a COM property that takes a parameter and so it falls back to the underlying method declaration where it essentially treats it as a method call that takes an index parameter and returns a string:

string thing = myObject.get_Item(2)  //  Boo!

These clients probably also missed the important fact that the property was marked as DISPID_VALUE.

Now with c#, you are arguably free to use the method-style operations to query a property or do as COM was designed and use index property notation.

After all, c# is OO; understands properties; understands indexers so why wouldn't you use them?

Hence why Resharper is prompting you to use the COM-preferred indexed style. It's no different to how you would use a regular c# class.

Upvotes: 1

toddmo
toddmo

Reputation: 22406

Resharper is trained to use properties instead of the underlying Getter because it's easier code to read and more OO-like. The property just calls the getter under the covers.

The COM port of Excel automation just exposed the Getter, even though this is not really all that OO-ish.

BTW, I recommend using Aspose Cells instead of Office automation. It's like ten trillion times faster.

Upvotes: 1

Related Questions