Hello,
I am getting an access violation on writing the sheet. EurekaLog tells me it comes from XLSHashTrie4, in TTreeItem.Clear. I put in some logging code, and have observed that the problem happens only when the number of entries exceeds LeafSize, and so requires lined items. I have found that by increasing the BucketSize constant, I can reduce the likelihood of the AV, but cannot prevent it. We have many different exports we generate, but only this one particular format is of sufficient complexity to show the problem, and even so, only when we include a second and third sheet in the output. Also, the behavior is not deterministic: If I get the AV, and try again, and get an AV again, on the third time, it will invariably work properly.
AV in write of sheet
Re: AV in write of sheet
Hello
The error is probably elsewhere than in XLSHashTri. This hash table don't have a limited size, it can grove to any size that memory permits. Changing BucketSize only affects performance. The most likely is that memory is corrupted, and by changing BucketSize you make this corruption less visible. Please test if the error occurs in version 5 of the component.
The error is probably elsewhere than in XLSHashTri. This hash table don't have a limited size, it can grove to any size that memory permits. Changing BucketSize only affects performance. The most likely is that memory is corrupted, and by changing BucketSize you make this corruption less visible. Please test if the error occurs in version 5 of the component.
Lars Arvidsson, Axolot Data
Re: AV in write of sheet
What happens, when it errors out, is that Items[92] contains a value which is not nil, and does not point to an object. So it AVs on:
if Items[j] is TTreeItem then
I have added logging code, and have seen that a) Items[92] was not assigned to, after the instance creation, and b) in the Clear method, Items[92] contains (on my machine) 19000000. The value is always the same. On other machines it is different, but also fixed.
To try the V5 trial version, do I need to uninstall V4? I ask because this is a big project, and if the two cannot co-exist, then about 70 units are affected.
Thanks,
if Items[j] is TTreeItem then
I have added logging code, and have seen that a) Items[92] was not assigned to, after the instance creation, and b) in the Clear method, Items[92] contains (on my machine) 19000000. The value is always the same. On other machines it is different, but also fixed.
To try the V5 trial version, do I need to uninstall V4? I ask because this is a big project, and if the two cannot co-exist, then about 70 units are affected.
Thanks,
Re: AV in write of sheet
Hello
No, you can have version 4 and 5 installed at the same time.
No, you can have version 4 and 5 installed at the same time.
Lars Arvidsson, Axolot Data
Re: AV in write of sheet
I tried it after I posted. When I change the component and save, it inserts in the uses clause references to two V5 units (XLSSheetData5, XLSReadWrite5), which of course are not available in the trial component.
Re: AV in write of sheet
Hello
This is how delphi works. The units (XLSSheetData5, XLSReadWrite5), as well as the rest of the units that the component uses, are available as DCU:s They are installed in the directory you choose when you installed the component. Add the search path to that dir and correct subdir (package) to your project.
This is how delphi works. The units (XLSSheetData5, XLSReadWrite5), as well as the rest of the units that the component uses, are available as DCU:s They are installed in the directory you choose when you installed the component. Add the search path to that dir and correct subdir (package) to your project.
Lars Arvidsson, Axolot Data
Re: AV in write of sheet
Yes, sorry, too much multi-tasking yesterday.
Our hope was to use V5 to quickly determine whether it was a solution to the HashTrie problem. I have seen a number of changes in the V5 component which break existing code, and we must now review our options. Because of breaking changes in V5, even though they may ultimately improve our situation overall, there is a substantial burden on QA, as well as on development.
Thanks.
Our hope was to use V5 to quickly determine whether it was a solution to the HashTrie problem. I have seen a number of changes in the V5 component which break existing code, and we must now review our options. Because of breaking changes in V5, even though they may ultimately improve our situation overall, there is a substantial burden on QA, as well as on development.
Thanks.