Subject | Fields[xx].value - unidentifyed type: 14 - Problem Solved |
---|---|
Author | Mauricio Longo |
Post date | 2001-01-12T03:59:16Z |
Jason,
Kim seems to have found a problem with the implementation of TLargeIntField,
regarding the SetValue method. This seems to be main problem leading to the
variants not getting correctly assigned to Integer fields when using the
Value property.
The variant type issue has more to do with how the compiler handles the
watches in the IDE than with our problem itself. The IDE can't show the
values of these variables in the watches or evaluate/modify windows.
I was able to work around the problem by changing TkbMemTable's code to use
AsString instead of Value. This way, when the Memory Table attempts to copy
the data the string convertion eliminates the problem. It seems to work ok,
so far.
I'm not experienced in handling variant internals either, however, we can
now presume that changing the variant hanling in IBO would not solve the
problem since it seems to reside in a class made by Borland.
Thanks for attention.
Best regards,
Mauricio Longo
Kim seems to have found a problem with the implementation of TLargeIntField,
regarding the SetValue method. This seems to be main problem leading to the
variants not getting correctly assigned to Integer fields when using the
Value property.
The variant type issue has more to do with how the compiler handles the
watches in the IDE than with our problem itself. The IDE can't show the
values of these variables in the watches or evaluate/modify windows.
I was able to work around the problem by changing TkbMemTable's code to use
AsString instead of Value. This way, when the Memory Table attempts to copy
the data the string convertion eliminates the problem. It seems to work ok,
so far.
I'm not experienced in handling variant internals either, however, we can
now presume that changing the variant hanling in IBO would not solve the
problem since it seems to reside in a class made by Borland.
Thanks for attention.
Best regards,
Mauricio Longo