XLSReadWriteII 5 migration issues

[actint]

Hello,

We have just purchased version 5 of XLSReadWriteII for the promises in the release notes about memory usage and speed improvements are what we are looking for. However, the migration is definitely not easy and this post will be quite lengthy.
For any of the changes I mention here, I can provide a diff file if need be as we store all our sources in SVN.
Here are the remarks:

- The fact that all files have been renamed means it's extremely hard to keep track of the changes we had made to version 4. And we did quite a few changes because we ported it to x64, fixed a few warnings and bugs. I know you intend on allowing to have all versions alongside each other, but that's of little use to us and thus very annoying. We use branches for that kind of things as it's much more flexible.

- As indicated by another member, the $I statements for all BIFF_ files are bogus, looks like the BIFF_ files were meant to be placed in their own subfolder.

- We have a "zero warning / zero hint" policy here and we expect third party vendors to have the same. However, in this case we had to modify 6 files for various unused variables, return value not set and suspicious casts.

- BIFF_EncodeFormulaII5 uses an ugly construct for its TTokenName constant where it could simply use array[TTokenType] of string

- BIFF_Utils5 and XLSHTMLParse5 both define the XLSGetHashCode function, which I found out because that function is NOT x64 compatible. In version 4 I had to fix it once, but now I had two places to apply the change. It is not compatible with x64 because the calling convention is not the same, the parameters are not in the same registers.

- Despite what the announcement email claims, version 5 is not compatible with x64 because it systematically casts pointers to integers. This MUST NOT be done and has to be replaced by casts to NativeUInt, or NativeInt when negative offsets may arise. I had to apply this type of change to 29 files just like I did for version 4, but I did not expect those bugs to still be here in version 5

- TXLSReadII.LoadFromStream inside BIFF_ReadII5 should let EAbort escape instead of reraising it as Exception. EAbort is meant to be silent, the current construct means it is replaced by a non silent exception. Getting EAbort here is quite simple, create a password handler that raises it when the user has decided to click "Cancel" on the dialog he has been presented.

- TXLSWorkbook is missing the SheetByName method, but it was easy to add it.

- TXLSWorkbook is missing a way to insert a new sheet at a given index. In v4, one wrote XLS.Sheets.Insert(Index) but now it's impossible and I could not find a trivial way to code it.

- TXc12DefinedNames uses a hash table to speed up the lookup of values, which is a good idea. However, this hash is almost always empty when reading an existing Excel file because names are added via the Add method that takes no parameters. The issue I encountered came from TXLSNames not being able to find a named cell area, so I fixed it by adding values to the hash table inside the TXLSNames.AfterRead method. I believe this issue should be looked at in more details because there are many cases when the hash is empty despite the list containing elements.


After all those changes I was able to compile our unit tests suites and run the basic ones. I'll move on to more in depth testing, especially related to memory usage and read speed, I hope the two days I have already spent were worth it...

Regards

[cenzin]

Friends,
I also instructed our people to buy the upgrade from V4 to 5 specifically for the 64 bits feature. The fact that it is not compatible with 64 bits is very bad. But this is not all. I'm porting the code to V5 and not even the samples are working. I'm receiving this error when i try to read an xlsx file:

First chance exception at $75FEC83B. Exception class Exception with message 'Unknown OPS type "http://schemas.openxmlformats.org/offic ... cheRecords" in save data'. Process SampleReadWriteCells.exe (7456)

[larsa]

Hello

Sorry for your hard work. If you find any bugs, please let me know directly. It took me less than an hour to fix what you mention. There may also be other issues, such as the GetHashCode function. It's never used anywhere and can be removed.

About errors in the sample, the problem is the file, not the sample. If you encounter a file that generates an error, please send it tom me.

[PStadler]

Hello Larsa

- TXLSWorkbook is missing a way to insert a new sheet at a given index. In v4, one wrote XLS.Sheets.Insert(Index) but now it's impossible and I could not find a trivial way to code it.

How can a new sheet be inserted?

If you fixed all these proposals done by actint, when this new version will be available?

Sincerely

Peter

[cenzin]

It might be the file, do not doubt it but that same file was readed flawlessly in xlsreadwriteii v4, Also this is no the only thing that is not working int he sample. If you take that file which is a xlsx file it will give you the error. But if you take an xls file it won't give you any error but it won't read it. I'm going to send both files for you to see. Hope that i can get feedback soon. I'm on a deadline with this porting. I thought that it was going to be straightforward...

[cenzin]

Hello larsa, did you receive the files i sent? They were sent via otgeosoft@gmail.com but i copied the registered email

[actint]

One of my colleague suggested to use Add then Move to put the spreadsheet in place, but then again, there's no Move to be seen anywhere...
In the responses to v5 questions, you always mention an upcoming version with the fixes. When will it be available?

Right now it feels that the current version was rushed out the door. Had it been marked "beta", I would have accepted the issues and wrote the message differently, but as it was not, I felt the urge to warn others that the version currently available for download has quite a few issues.

I'm eagerly waiting for the next version with all the fixes.

[larsa]

Hello

I understand that it feels hard for you that you have wasted several days of your time on fixing bugs in unused code and things that took me minutes to correct. I'm on vacation now and can't update the downloads until I'm back in office on the 20th. There have never been a Move (sheets) method in any previous version, so it's not missing. I will lock this thread now as your postings starts to look more like insults.