Writing double precision to Excel

Question

Hi folks,
as others, I am having problems with writing doubles to Excel with the new Report Generation Toolkit.
My problems are due to localized decimal points and as far as I figured out, this makes it impossible to use the "EasyExcel Table.vi", feeding in a numeric array as designed. It might be that this problem is due to the writing, then backreading and rewriting of the table, programmed by NI in the "Excel_Insert_Table.vi" (fig. 1). At least the code does not make sense to me .
A solution like converting the numbers to text myself and then sending the text to Excel becomes very clumsy, when I have to check for the country settings, convert points to commas and vice versa and in addition, I did not find out how to read these settings programmatically.
Now, I just recently figured out an elegant solution to the problem that I implemented for the previous version of the Toolkit: Don't convert the numbers but transfer them to Excel in binary format (fig. 2).
Excel (2003 at least) understands these numbers perfectly. I thus programmed a custom "EasyExcel TableHL.vi" (including its subVIs), in order not to change the Toolkit library.
Now, due to problems with Office 2007, I have to upgrade to the new toolkit version and I do not know, how to deal with the new object oriented approach.
It is clear, the easiest solution to my problem would be, NI fixing it by writing non converted numbers to Excel (as you expect from the appearance of "EasyExcel Table.vi" ).
A second solution would be to modify the the toolkit, which I don't like.
The third way then is to learn OOP, build a new class with the desired functionality ........ , leaving the toolkit untouched.
Now my question is: Does anybody have a fourth possibility or can anybody give me a hint, how laborious it will be, to dig into OO-programming to do the above described work?
Thank's in advance.
Herbert
Attachments:
Excel_Insert_Table.jpg ‏123 KB
write DBL to Excel.jpg ‏118 KB

Answer 1

Hello Marian,
the toolkit I am using is 1.1.3 together with LabVIEW 8.6.
Now, since I do need a solution due to customers waiting, I tried to modify the Office-library and I succeeded.
This means, I am very thankful to NI that it did not protect all the VI's by password, as it did with the classes. This fact enabled me to implement my solution into NI's VI's and become unsensitive to  the country settings of the customer.
Now, since only "non-protection" made this simple solution possible, I would like to ask NI to protect as few code as possible. I know, NI does so in order to protect it's intellectual property. On the other hand, open code provides the user the possibility to correct bugs himself, which can be "vital" in some situations (according to my experience, this happens seldom, but it does happen).
Thank's
Herbert