mudrii
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Для тех, кто пользуется компонентами не безызвестного разработчика с сайта Axolot.
Возможно задумаются о замене?!
Реальное положение дел весьма недвусмысленно выражено в этом посте, даю в оригинале
Цитата: Axolot - Poor quality excel components
XLSReadWrite reviewed
Third-party component vendors are kingmakers in Delphi community. They needed to be treated with reverence, praised highly and meagre output they produce is sold at high price.
For fun component
XLSReadWriteII is for fun. Axolot is not serious in fixing bugs by asking for annual upgrade and components keeps crashing. The vendor ignores older support requests for older versions of XLSReadWrite.
Axolot does not seem to be interested to fix last year's version of his own work. Instead, Axolot asks you to upgrade for Euros 195 as that is not a free update. If you fail to pay the upgrade and lapse for a year, sorry, you must pay for the full license again, Euro 295. Trial users get very limited support, so if you evaluate too long, your posts on the Axolot forums are ignored.
XLSReadWrite II v5 is called the Ultimate solution to access Excel files with Delphi and C++ Builder, except it does not fully support XLSX, XLSXM file format. Charts are not supported, with the vendor not implementing it since version 4. It will be released in v6 (maybe next year?) or maybe in v7 (in 2015) or maybe in v8 (2016) while this feature is not implemented. Encrypted saves are not supported. Firemonkey support is not added yet. XLSM is read-only support, so you can read but cannot write to such files.
Developers porting the older version to v5 get rude shock when there are so many problems with Axolot.
"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...
and the Axolot vendor replies with:
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.
On the Axolot forums, there are so many posts where the vendor replies 'This functionality is not yet supported in the current version, maybe in a future version'.
If you run some Axolot commands in the wrong sequence or just run the command without running some other command earlier, it will cause a crash.
The vendor gives bizarre support for technical questions, such as, stop eating potatoes, calling others a moron. Like many Delphi vendors, they only sell libraries, not full products. Thus, they do not feel what customers feel. Customers get bad quality component, waste time on non-searchable help files, bad support.
In the NET market, Axolot is nearly non-existent as C# vendors can easily get well-made libraries such as SyncFusion's XLSIO and TMS Flexcell.NET.
Posted by Delphi Haters at Thursday, April 03, 2014 |
Взято с дружественного сайта. |
Всего записей: 885 | Зарегистр. 17-02-2003 | Отправлено: 07:11 06-04-2014 | Исправлено: mudrii, 07:13 06-04-2014 |
|
)) 
