Error when reading Cell(x,y).BackgroundColor.Color Property

Aug 27, 2012 at 10:03 PM

Hi  - I'm doing a proof of concept for my boss using the ClosedXML tool (cool stuff!!), but I'm running into some issues right off the bat having to do with accessing a cell's background color information. The BackgroundColor.Color property & subproperties work fine on some cells but on others I'm getting a show-stopping error:

System.Collections.Generic.KeyNotFoundException was unhandled
  Message="The given key was not present in the dictionary."
       at System.ThrowHelper.ThrowKeyNotFoundException()
       at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
       at ClosedXML.Excel.XLColor.get_Color()


Perhaps due to the cell's color being set to default - maybe having no name at all? Maybe it's considered a Null. The cells I've found it seems to have a problem with (so far) have the "No Color" (Excel default) background color.

For my particular needs, I need to be able to distinguish cells based on their color - and I was hoping to use the .A, .R, .G, .B, Color.Name (or Hex information??) - all of which throw this exception on cells with a "No Color" background. Any ideas on how to handle this?

-- Could this be a larger problem with ANY color which is not part of the Static member colors you have (AntiqueWhite, Aqua, etc)??

Thanks for your reply



Aug 27, 2012 at 10:16 PM

The default is an indexed color of 64 (No Color). As expected "No Color" has no direct translation to a Color class. I honestly don't know how handle this situation because returning ARGB(0, 0, 0, 0) doesn't feel quite right (it's not really a 0% opaque black color).

What do you think?

Aug 28, 2012 at 3:10 PM
Edited Aug 28, 2012 at 3:12 PM

Error handling will be easy on this end by searching for that index of 64 first, so it's not that bad. I'm just not a fan of maintaining eNums or "magic" numbers that need explanation. That's always confusing to whatever coder is maintaining the code 4 years later.

Excel displays the "No Color" as white. Maybe No Color should return all the internal info of a pure white but maintain it's "blank" 64 index? That would solve the issue for me, I think - and not be too misleading. Without something like that, anyone matching colors the way I am will have to add their own error handling to cover the most common background color situation they'll face.

I don't know if my suggestion the best way to handle it or not. But I do think adding a blurb about how to handle No Color in the documentation the way it is presently would be good until a better way is implemented. I'll be messing with the tool for the next couple of days - if I think of a way to handle it better, I'll post.



Aug 28, 2012 at 8:18 PM

bah, I didn't know there's a transparent color (perfect for this scenario). Indexed color 64 now maps to Color.Transparent

Pick up the latest code. Thanks for the help.