Hi @Greg Whitten,

I looked into this, there are two things going on:

1. GetAllRules is the red herring. It doesn't actually read the rule's Style back, so it always reports default values no matter what's on the rule. That's a bug on my side (fix coming) — so an empty Style there doesn't mean your formatting failed.
2. The fill itself applies fine in my tests. I added an Expression rule with a solid fill, saved, and reopened — the fill is there in the file.

To pin down your case:

• Which version of Advanced Excel are you on?
• When you open the generated file in Excel, does the cell actually fill (vs. just going by GetAllRules)?
• Is Pattern Type set to Solid? (A color with PatternType = None won't show.)
• What's your Expression formula — does it evaluate TRUE for those cells?

Either way, the GetAllRules fix will be in the next release.

Hi Ricardo,

I'm using the latest version as of June 29.  

The rule exists but with no format: 

If I set a format by editing the rule then the cells change color.

I'm configuring my style like so:

Hi @Greg Whitten,

Found the root cause. In your version, a 6-digit hex color like #FF0000 is being parsed with an alpha of 0 (fully transparent). It gets written into the file as an invalid 6-digit color (rgb="ff0000" instead of the required 8-digit rgb="ffff0000"), so Excel can't read the fill and shows it as "No Format Set" — even though the rule and formula are correct.

Workaround you can use right now: add an explicit FF (opaque) alpha to the front of the color — so use #FFFF0000 instead of #FF0000, for both Background Color and Pattern Color. Keep Pattern Type = 1 (Solid).

I've attached a file (CF_WORKAROUND_FFFF0000.xlsx) generated with the exact Expression rule you're using (=E2<>O2, solid fill), just with the FF alpha prefix — open it and you'll see the fill applies correctly. It was produced through the actual extension code on a build matching your version, so it's a real reproduction, not a mock-up.

Proper fix: this is resolved in the upcoming 2.7.1 release — 6-digit hex colors will be treated as opaque, so #FF0000 will just work, no prefix needed.

(Also, heads up: ConditionalFormatting_GetAllRules currently doesn't read the rule's style back, so it always reports defaults — don't use it to verify formatting. That's fixed in 2.7.1 too.)

Hope this unblocks you

Can you attach the OML?  I tried "#FFFF0000" and "FFFF0000" and I still get No Format Set

Actually, I got it to work.  The issue is elsewhere and it has something to do with starting with RecordListToExcel and then modifying that with AdvancedExcel.

Originally my flow was:

1. RecordListToExcel
2. Workbook_Open_Binary_Data (with 1)
3. Worksheet_Select (with 2)
4. Worksheet_GetProperties (with 3)
5. ConditionalFormatting_AddRule (with 3)
6. Workbook_GetBinaryData (with 2)

But this was causing a null reference exception to throw on step 6, so I adjusted to:

1. RecordListToExcel
2. Workbook_Open_Binary_Data (with 1)
3. Worksheet_Select (with 2)
4. Worksheet_GetProperties (with 3)
5. ConditionalFormatting_AddRule (with 3)
6. Workbook_Create
7. Workbook_AddSheet (with 6 and 3)
8. Worksheet_Delete (with 6 to remove the default sheet)
9. Workbook_GetBinaryData (with 6)

This got rid of the exception, but the rule lost its format somehow when adding the sheet to the new workbook.  I added another get of the worksheet and added the rule to that ending up with:

1. RecordListToExcel
2. Workbook_Open_Binary_Data (with 1)
3. Worksheet_Select (with 2)
4. Worksheet_GetProperties (with 3)
5. Workbook_Create
6. Workbook_AddSheet (with 5 and 3)
7. Worksheet_Delete (with 5 to remove the default sheet)
8. Worksheet_Select2 (with 5)
9. ConditionalFormatting_AddRule (with 8)
10. Workbook_GetBinaryData (with 5)

This is working for me now.  A little convoluted, but it works,

Awesome, thanks!  I'll check out the new version.