Issues with xl files generated by openpyxl

[ddTech]

Hi!

I have to make use of xl files as a data source that obviously are being createde by a tool called openpyxl and ran into some issues trying to accomplish this with the vfpXWorkbookXLSX-Class.

I have no idea how common the use of this openpyxl tool is and if this needs to be addressed here at all.
However I want to share my findings with You in case someone else runs into this (these) or similar problems.

An attempt to open a openpyxl xlsx file with vfpXWorkbookXLSX::openXLSXWorkbook() silently fails. It runs through without complaint but.GetLastRowNumber(1,1)returns 0. A closer look at the tables shows that XL_CELLS has no records.

Excel is able to open the file.
The good news is: once the the file has been saved with Excel, it can be used with vfpXWorkbookXLSX as well.
So, if manual steps are necessary and You have Excel at hand, just make sure You open and save the file with Excel once You got it. Then You're good to go.

However, as this might not always be possible and I was interested in finding the culprit, I started to track what's going on.
I found that they are not consistently unsing paths in xl\_rels\workbook.xml.rels.
worksheets start with /xl/worksheets/sheet... instead of worksheets/sheet...
Added to lcWbXmlPath this makes the if ADIR(laTemp, lcFile) > 0 fail and completely skip the file.

So I added a simple path check to openXLSXWorkbook()

	DO WHILE !EMPTY(lcRelation)
		lcRelId    = this.GetNodeAttributeValue(lcRelation, "Id")
		lnRelId    = CAST(SUBSTR(lcRelId, 4) AS I)
		lcTarget   = this.GetNodeAttributeValue(lcRelation, "Target")
		
		*-- DD changed on 27.10.25
		*-- Fix inconsistent path on files generated by openpyxl
		*-- They use 
		*--		Target="/xl/worksheets/sheet1.xml" 
		*-- instead of 
		*-- 	Target="worksheets/sheet1.xml"
		*-- which leads to ...\xl\/xl/worksheets/... 
		*-- -> ADIR(laTemp...) = 0 -> sheet ignored
		if left(lower(m.lcTarget), 4) == "/xl/"
			m.lcTarget = substr(m.lcTarget, 5)
		endif

		lcRelType  = this.GetNodeAttributeValue(lcRelation, "Type")
		lcRelType  = SUBSTR(lcRelType, RATC("/", lcRelType)+1)
		lcFileName = lcWbXmlPath + lcTarget
		IF ADIR(laTemp, lcFileName) > 0
			DO CASE

That solves the problem and the XLSX File can be used directly

That was problem no. 1

Preparing a cursor with the data from the XLSX I realized that now all empty cells were filled with a string that happens to be the first caption (i.e. cell A1).
I found that in XL_CELLS these cells had a CellValue of "StringValue" were of DataType "C" and had a StringID of 0. As the StringID of cell A1 is 0 they all were filled with this value.
In the Excel-saved version these where empty CellValues of DataType "X".

So I had a closer look at sheet1.xml and found that empty cells look like <c r="F2" s="2" t="s"></c>
No v but a t attribute.
In the Excel-saved version there is also no 'v' attribute but it's lacking the 't' attribute as well (<c r="F2" s="2"/>).
The t attribute is being evaluated in .readCellValueFormat() and with a value of "s" it results in a DataType CHAR that is expected to also come with a v holding the StringNdx, which here is not the case. Thus the default index of 0 is being returned.

I was not sure about the lcCellType == "str" so I added a one liner with with an empty() check on lcCellType =="s"

	DO CASE
		CASE lcCellType == "f"
			loCell.DataType = DATA_TYPE_FORMULA
			
		*-- DD changed on 27.10.25
		*-- type "s" but no "v" attribute 
		*-- like provided in openpyxl with empty cells.
		*-- something like 
		*-- ... <c r="F2" s="2" t="s"></c> ...
		*-- instead of 
		*-- ... <c r="F2" s="2"/> ... 
		*-- as would be found in files saved by Excel
		CASE m.lcCellType == "s" and empty(m.loCell.CellVal)
			*-- keep empty DATA_TYPE_NONE

		CASE lcCellType == "s" .OR. lcCellType == "str"
			loCell.StringNdx = CAST(loCell.CellVal AS I)
			loCell.CellVal   = "StringValue"
			loCell.DataType  = DATA_TYPE_CHAR
	
		CASE lcCellType == "inlineStr"

I guess, modifying the original line to CASE (lcCellType == "s" .OR. lcCellType == "str") AND ! empty(m.loCell.CellVal) should work well in this case.

Problem no. 2 solved as well.

Looking good so far. But then I ran into a "data type error".
A cell of type date was identified as integer in XL_CELLS. Excel sees it as date, I found the corresponding definition in styles.xml and XL_CELLXFS and XL_NUMFMTS have them as well.
It took me a while to understand what's wrong in this case. And there is actually nothing wrong per se. The problem here lies in the order of operation.

In the xl\_rels\workbook.xml.rels of the openpyxl generated file worksheets appear on top of styles and themes. So when the sheets are being processed, styles are not yet available.
If I manually reorder the entries everything is fine.

So in order to solve this, my first idea was to order the entries by rId in a descending order, but I found XLSX files created with another tool (Apache POI) where the entries have the correct order and have ascending rId's. So that would compromize these applications.

I have no solution to that yet. I guess instead of just iterating through the .rels file one has to check and pick the entries in a defined order. But I am not familiar with the matter and don't know much about the dependencies of the individual modules.

My current workaround here is to leave the .rels file untouched and to check for integer cells that should be of type date
Something like

	m.lvValue = m.loXL.GetCellValue(1, 1, m.lnR, m.laColDefs[m.lnI,1])    

	...

	if m.laColDefs[m.lnI,3] = "D" and vartype(m.lvValue) = "N" 
		*-- Kommt ein Datum als Integer?
		m.lvValue = {^1899-12-30} + m.lvValue			
	endif 

Not a true solution, but works for my current needs.

I have not looked at / tried the openXLSXWorkbookEx() and other ...Ex() variants yet.

I hope this is useful

Kind regards from Berlin

Frank

[ggreen86]

Hello— Thank you for your research and code solutions. Can you please send me a sample xlsx file that is generated with openpyxl? Thank you. Greg From: ddTech ***@***.***> Sent: Monday, October 27, 2025 9:38 AM To: ggreen86/XLSX-Workbook-Class ***@***.***> Cc: Subscribed ***@***.***> Subject: [ggreen86/XLSX-Workbook-Class] Issues with xl files generated by openpyxl (Issue #146) [Image removed by sender.]ddTech created an issue (ggreen86/XLSX-Workbook-Class#146)<#146> Hi! I have to make use of xl files as a data source that obviously are being createde by a tool called openpyxl and ran into some issues trying to accomplish this with the vfpXWorkbookXLSX-Class. I have no idea how common the use of this openpyxl tool is and if this needs to be addressed here at all. However I want to share my findings with You in case someone else runs into this (these) or similar problems. An attempt to open a openpyxl xlsx file with vfpXWorkbookXLSX::openXLSXWorkbook() silently fails. It runs through without complaint but.GetLastRowNumber(1,1)returns 0. A closer look at the tables shows that XL_CELLS has no records. Excel is able to open the file. The good news is: once the the file has been saved with Excel, it can be used with vfpXWorkbookXLSX as well. So, if manual steps are necessary and You have Excel at hand, just make sure You open and save the file with Excel once You got it. Then You're good to go. However, as this might not always be possible and I was interested in finding the culprit, I started to track what's going on. I found that they are not consistently unsing paths in xl\_rels\workbook.xml.rels. worksheets start with /xl/worksheets/sheet... instead of worksheets/sheet... Added to lcWbXmlPath this makes the if ADIR(laTemp, lcFile) > 0 fail and completely skip the file. So I added a simple path check to openXLSXWorkbook() DO WHILE !EMPTY(lcRelation) lcRelId = this.GetNodeAttributeValue(lcRelation, "Id") lnRelId = CAST(SUBSTR(lcRelId, 4) AS I) lcTarget = this.GetNodeAttributeValue(lcRelation, "Target") *-- DD changed on 27.10.25 *-- Fix inconsistent path on files generated by openpyxl *-- They use *-- Target="/xl/worksheets/sheet1.xml" *-- instead of *-- Target="worksheets/sheet1.xml" *-- which leads to ...\xl\/xl/worksheets/... *-- -> ADIR(laTemp...) = 0 -> sheet ignored if left(lower(m.lcTarget), 4) == "/xl/" m.lcTarget = substr(m.lcTarget, 5) endif lcRelType = this.GetNodeAttributeValue(lcRelation, "Type") lcRelType = SUBSTR(lcRelType, RATC("/", lcRelType)+1) lcFileName = lcWbXmlPath + lcTarget IF ADIR(laTemp, lcFileName) > 0 DO CASE That solves the problem and the XLSX File can be used directly That was problem no. 1 Preparing a cursor with the data from the XLSX I realized that now all empty cells were filled with a string that happens to be the first caption (i.e. cell A1). I found that in XL_CELLS these cells had a CellValue of "StringValue" were of DataType "C" and had a StringID of 0. As the StringID of cell A1 is 0 they all were filled with this value. In the Excel-saved version these where empty CellValues of DataType "X". So I had a closer look at sheet1.xml and found that empty cells look like <c r="F2" s="2" t="s"></c> No v but a t attribute. In the Excel-saved version there is also no 'v' attribute but it's lacking the 't' attribute as well (<c r="F2" s="2"/>). The t attribute is being evaluated in .readCellValueFormat() and with a value of "s" it results in a DataType CHAR that is expected to also come with a v holding the StringNdx, which here is not the case. Thus the default index of 0 is being returned. I was not sure about the lcCellType == "str" so I added a one liner with with an empty() check on lcCellType =="s" DO CASE CASE lcCellType == "f" loCell.DataType = DATA_TYPE_FORMULA *-- DD changed on 27.10.25 *-- type "s" but no "v" attribute *-- like provided in openpyxl with empty cells. *-- something like *-- ... <c r="F2" s="2" t="s"></c> ... *-- instead of *-- ... <c r="F2" s="2"/> ... *-- as would be found in files saved by Excel CASE m.lcCellType == "s" and empty(m.loCell.CellVal) *-- keep empty DATA_TYPE_NONE CASE lcCellType == "s" .OR. lcCellType == "str" loCell.StringNdx = CAST(loCell.CellVal AS I) loCell.CellVal = "StringValue" loCell.DataType = DATA_TYPE_CHAR CASE lcCellType == "inlineStr" I guess, modifying the original line to CASE (lcCellType == "s" .OR. lcCellType == "str") AND ! empty(m.loCell.CellVal) should work well in this case. Problem no. 2 solved as well. Looking good so far. But then I ran into a "data type error". A cell of type date was identified as integer in XL_CELLS. Excel sees it as date, I found the corresponding definition in styles.xml and XL_CELLXFS and XL_NUMFMTS have them as well. It took me a while to understand what's wrong in this case. And there is actually nothing wrong per se. The problem here lies in the order of operation. In the xl\_rels\workbook.xml.rels of the openpyxl generated file worksheets appear on top of styles and themes. So when the sheets are being processed, styles are not yet available. If I manually reorder the entries everything is fine. So in order to solve this, my first idea was to order the entries by rId in a descending order, but I found XLSX files created with another tool (Apache POI) where the entries have the correct order and have ascending rId's. So that would compromize these applications. I have no solution to that yet. I guess instead of just iterating through the .rels file one has to check and pick the entries in a defined order. But I am not familiar with the matter and don't know much about the dependencies of the individual modules. My current workaround here is to leave the .rels file untouched and to check for integer cells that should be of type date Something like m.lvValue = m.loXL.GetCellValue(1, 1, m.lnR, m.laColDefs[m.lnI,1]) ... if m.laColDefs[m.lnI,3] = "D" and vartype(m.lvValue) = "N" *-- Kommt ein Datum als Integer? m.lvValue = {^1899-12-30} + m.lvValue endif Not a true solution, but works for my current needs. I have not looked at / tried the openXLSXWorkbookEx() and other ...Ex() variants yet. I hope this is useful Kind regards from Berlin Frank — Reply to this email directly, view it on GitHub<#146>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AGWB33NVQ25MGBJ222PDBND3ZYGZJAVCNFSM6AAAAACKKM5UROVHI2DSMVQWIX3LMV43ASLTON2WKOZTGU2TMOBTHA2DQNY>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ddTech]

Hi Greg,

Thank you for your research and code solutions.
Can you please send me a sample xlsx file that is generated with openpyxl? Thank you.

I already thought about that but the files contain personal and sensitive data.
Normally I would just anonymize them, but in order to do that, I'd have to touch the file.

Maybe I can retrieve a filtered view with just a few records, open the zip file and edit the xml manually.

I'll check if I can make up something usefull for You.

regards

Frank

[ggreen86]

Keep in mind of text that is sensitive that is stored in the strings.xml file. You could change the sensitive text in this file by changing all the text to “sensitive”. Not sure if any numeric value would be sensitive. From: ddTech ***@***.***> Sent: Monday, October 27, 2025 1:17 PM To: ggreen86/XLSX-Workbook-Class ***@***.***> Cc: ggreen86 ***@***.***>; Comment ***@***.***> Subject: Re: [ggreen86/XLSX-Workbook-Class] Issues with xl files generated by openpyxl (Issue #146) [Image removed by sender.]ddTech left a comment (ggreen86/XLSX-Workbook-Class#146)<#146 (comment)> Hi Greg, Thank you for your research and code solutions. Can you please send me a sample xlsx file that is generated with openpyxl? Thank you. I already thought about that but the files contain personal and sensitive data. Normally I would just anonymize them, but in order to do that, I'd have to touch the file. Maybe I can retrieve a filtered view with just a few records, open the zip file and edit the xml manually. I'll check if I can make up something usefull for You. regards Frank — Reply to this email directly, view it on GitHub<#146 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AGWB33KRUDNZTCNV3ZQTVKD3ZZAOVAVCNFSM6AAAAACKKM5UROVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTINJSGQ2TEMBWGY>. You are receiving this because you commented.Message ID: ***@***.***>

[ddTech]

Hi Greg,

Keep in mind of text that is sensitive that is stored in the strings.xml file. You could
change the sensitive text in this file by changing all the text to “sensitive”.
Not sure if any numeric value would be sensitive.

yes, sure that's where the readable information is. Numeric data is not much of a problem in this case.

Here is a file that only contains captions and two records, but should have all the issues I fell over.
Checked it with the unmodified R51 (-> fail to open) as well as with my modifications.

openpyxl_demo.zip

I'm also attaching my modified version. Maybe some cleanup needed, but should be good for testing.

VFPxWorkbookXLSX_R51_modified_2025-10-27.zip

I just touched .openXLSXWorkbook() and .readCellValueFormat()
... and fixed the typo in .setDefaultFont()

regards

Frank

[ggreen86]

Frank--

Thank you again for debugging this. I have incorporated your suggestions slightly differently. I added a method to check for the /xl/ preceding the path and correct. For the improper assignment of 0 for the string fields with an empty value, I moved up the CASE for when I test for the empty value. For your last problem, I added a first loop for processing the styles.xml first, and then all the other files in the workbook.xml.rels. This way the styles.xml is processed before any sheet.xml regardless of order.

I have attached the preliminary zip file to this message for you to test. Hopefully, I have not created any bugs by typos. It is late now and I will have to test the class tomorrow.

Greg

VFPxWorkbookXLSX R52 beta.zip

[ddTech]

Greg,

Thank you again for debugging this. I have incorporated your suggestions slightly differently. ...

Yes sure. Mine were just quick fixes for this particular case.

For your last problem, I added a first loop for processing the styles.xml first

Right, either a two step loop or a catalog of possible entries with defined order. Those would have been my choices too. But if You don't know about the possible values or the dependencies this would have become pure trial an error.

The beta seems to work well for me. Thanks!

I'll have to check out the openXLSXWorkbookEx() and see if it would help me to speed up things a bit. So far I did not have much luck with it.

Have a great day

regards

Frank

[ggreen86]

Frank— Note that the openXLSXWorkbookEx() method only opens for read-only and does not ‘convert’ the cell data values – those are stored ‘as-is’ directly to the xl_cells cursor. You would need to know the data type as the developer to interpret the values; i.e. date, datetime, etc. Read the documentation for more information on some helper methods. I will also look at this method for any impacts as well due to Openpyxl. Greg From: ddTech ***@***.***> Sent: Tuesday, October 28, 2025 10:24 AM To: ggreen86/XLSX-Workbook-Class ***@***.***> Cc: ggreen86 ***@***.***>; Comment ***@***.***> Subject: Re: [ggreen86/XLSX-Workbook-Class] Issues with xl files generated by openpyxl (Issue #146) [Image removed by sender.]ddTech left a comment (ggreen86/XLSX-Workbook-Class#146)<#146 (comment)> Greg, Thank you again for debugging this. I have incorporated your suggestions slightly differently. ... Yes sure. Mine were just quick fixes for this particular case. For your last problem, I added a first loop for processing the styles.xml first Right, either a two step loop or a catalog of possible entries with defined order. Those would have been my choices too. But if You don't know about the possible values or the dependencies this would have become pure trial an error. The beta seems to work well for me. Thanks! I'll have to check out the openXLSXWorkbookEx() and see if it would help me to speed up things a bit. So far I did not have much luck with it. Have a great day regards Frank — Reply to this email directly, view it on GitHub<#146 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AGWB33OWL2ZT4VWU3EKLWPL3Z5373AVCNFSM6AAAAACKKM5UROVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTINJWG4ZTKNJXGA>. You are receiving this because you commented.Message ID: ***@***.***>

[ddTech]

Hi Greg,

Note that the openXLSXWorkbookEx() method only opens for read-only and does not ‘convert’ the cell data... >> Read the documentation for more information on some helper methods.

Thanks for the hint, I read the notes and the project I'm working on would be the perfect use case for that.
I am working with a given structure and already do have a conversion table with indices, field names, data types and even conversion functions for specific fields.

There is one master system that is providing data for two other systems. All three have different structures and ways to store and display data. All three also do have records the other two should not have.
So I am taking export files from all three systems, bring them into a comparable structure by createing intermediate cursors, then compare field by field and finally create differential cursors. These then become XLSX and XML-Files as imports for the two child system.
For the first part fast read only access is just perfect.

It works well with openXLSXWorkbook(). So there is no need to try the other out right now, but I'll keep You updated.

I will also look at this method for any impacts as well due to Openpyxl.

Thanks for that!

Frank

[ggreen86]

Frank--

Please download and test the latest version (Release 52) that I have now posted. There are changes that affect both the sheet cell values and the styles.xml processing. I am now opening and saving the sample file that you provided without errors.

Greg

[ddTech]

Good Morning Greg,

no, unfortunately the official R52.beta download does not work well.

In XL_CELLS dates now have an empty CellValue and are of DataType X
and empty cells are of DataType C with a CellValue of "StringValue" and a StringId of -1

In my resulting VFP-Cursor all dates are empty and empty cells now appear as "StringValue".

The R52.beta You sent me yesterday is working perfectly fine, seeing dates as dates and empty cells remain empty.

Frank

[ggreen86]

Frank--

The tests that I run with cells that have date values works as expected. I typically run the Demo() method to generate a workbook and then use that file to read and write as a copy. In this file, date values are correctly copied to the new file. To try to duplicate the issue you are seeing I created a test spreadsheet that had a number of cells with date values and formulas involving the date values. I also formatted some empty cells as a date format. This file too is being read and copied correctly. Looking at the xl_cells cursor, the values in cellvalue field are correct (an untranslated date value) or empty. For dates that are before 1/1/1900 Excel stores these as strings and treats them as strings (you can't use in a formula to add a value to it). Since these are treated by Excel as strings (even if explicitly set to a date format), these values are stored in the sharedstrings.xml file by Excel. In xl_cells, these are identified as a "StringValue" with a StringId value >= 0; to get the value for the date, you have to use xl_strings.

Attached are the dates.xlsx file that I tested with and the resulting file that is read and copied (DATES_2.xlsx).

Dates.zip

It would be helpful if you can provide a sample file that will reproduce the issues that you are seeing in R52 beta.

Thank you.

Greg

[ddTech]

Hi Greg,

the .demo() does not work for me.
I get a wait window "Add Image failed". It's expecting the vfpbannar.gif in the working directory and addImage wants the gdi+ system app to be loaded.
If I provide both, .demo() runs without complaint, but Excel crashes as soon as I open the file.
if I comment the addImage() parts out, the resulting xlsx is slightly smaller but still crashes Excel once I try to open the demo file. ;-(

Nevertheless, Dates.xlsx and Dates_2.xlsx do work fine here too. Both betas interpret the given dates in the same way. Both seem to see cells B1 and B2 as floats though. Is that the way it should be here?

The File I tried the beta with was the openpyxl file I sent You the day before yesterday.
If I open that with the beta from yesterday, everything is fine but when I use the official beta it misbehaves.

openpyxl_demo.zip

This is what I see, when I use the "private" beta from here:

And this is what I get, when I use the public beta:

Frank

[ggreen86]

Frank— Just curious – what version of Excel are you using. I have Office 16 Pro installed. Greg From: ddTech ***@***.***> Sent: Wednesday, October 29, 2025 2:26 PM To: ggreen86/XLSX-Workbook-Class ***@***.***> Cc: ggreen86 ***@***.***>; Comment ***@***.***> Subject: Re: [ggreen86/XLSX-Workbook-Class] Issues with xl files generated by openpyxl (Issue #146) [Image removed by sender.]ddTech left a comment (ggreen86/XLSX-Workbook-Class#146)<#146 (comment)> Hi Greg, the .demo() does not work for me. I get a wait window "Add Image failed". It's expecting the vfpbannar.gif in the working directory and addImage wants the gdi+ system app to be loaded. If I provide both, .demo() runs without complaint, but Excel crashes as soon as I open the file. if I comment the addImage() parts out, the resulting xlsx is slightly smaller but still crashes Excel once I try to open the demo file. ;-( Nevertheless, Dates.xlsx and Dates_2.xlsx do work fine here too. Both betas interpret the given dates in the same way. Both seem to see cells B1 and B2 as floats though. Is that the way it should be here? grafik.png (view on web)<https://github.com/user-attachments/assets/36f4c6b7-35e9-4752-bd92-7f2649aeb051> grafik.png (view on web)<https://github.com/user-attachments/assets/192fe1fe-8849-43c4-b83f-b2537d632c51> The File I tried the beta with was the openpyxl file I sent You the day before yesterday. If I open that with the beta from yesterday, everything is fine but when I use the official beta it misbehaves. openpyxl_demo.zip<https://github.com/user-attachments/files/23216467/openpyxl_demo.zip> This is what I see, when I use the "private" beta from here: grafik.png (view on web)<https://github.com/user-attachments/assets/ac8e5dbe-3277-4ba1-8c10-dda88417b6b5> And this is what I get, when I use the public beta: grafik.png (view on web)<https://github.com/user-attachments/assets/b7a359dd-2c3e-4057-8f6d-20caf1b55f7c> Frank — Reply to this email directly, view it on GitHub<#146 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AGWB33PUR77UP5YPVC5YSCT32EBERAVCNFSM6AAAAACKKM5UROVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTINRTGA3TENBUGU>. You are receiving this because you commented.Message ID: ***@***.***>

[ddTech]

Greg,

Just curious – what version of Excel are you using. I have Office 16 Pro installed.

it's an ancient Excel 2007 :-D

Not a modern reference, but always good for compatibility tests

Frank

[ggreen86]

Frank— That might be the problem you are having with the Demo spreadsheet (and possibly others). Please open the demo generated spreadsheet and then do a repair. Send the ‘repaired’ version to me so that I can compare what files changed and how it changed the structure of the xml files. I attached the Demo generated file for you to use. Greg From: ddTech ***@***.***> Sent: Wednesday, October 29, 2025 3:35 PM To: ggreen86/XLSX-Workbook-Class ***@***.***> Cc: ggreen86 ***@***.***>; Comment ***@***.***> Subject: Re: [ggreen86/XLSX-Workbook-Class] Issues with xl files generated by openpyxl (Issue #146) [Image removed by sender.]ddTech left a comment (ggreen86/XLSX-Workbook-Class#146)<#146 (comment)> Greg, Just curious – what version of Excel are you using. I have Office 16 Pro installed. it's an ancient Excel 2007 :-D Not a modern reference, but always good for compatibility tests Frank — Reply to this email directly, view it on GitHub<#146 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AGWB33LJ6CYBU6ORRJ46JBD32EJGHAVCNFSM6AAAAACKKM5UROVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTINRTGUYTENRXHA>. You are receiving this because you commented.Message ID: ***@***.***>