Community
Participate
Working Groups
A Variant of Type VT_DATE will be always convertet to VT_R4 instead of VT_R8 leading to wrong results. I think it is a good idea to change the code in the class Variant after line 1020 in the default case of setData. It tries to convert to VT_R4 and VT_I4, this can be changed to VT_R8 and VT_I8 to increase precision.
Hi Stefan, Could you attach a sample code snippet demonstrating this problem.
Here is a sample code showing the precision problem itself. { final double in = 40000 + 1.0 / 24; // Add a fraction of 1/24 that means an hour System.out.println(in); int /*long*/ newPData = OS.GlobalAlloc(OS.GMEM_FIXED | OS.GMEM_ZEROINIT, VARIANT.sizeof); COM.MoveMemory(newPData, new double[]{in}, 8); Variant v1 = new Variant(newPData, (short)(OLE.VT_DATE | OLE.VT_BYREF)); System.out.println(v1.getString()); System.out.println(v1.getFloat() + " --> As you can see, its rounded"); System.out.println(v1.getDouble() + " --> Only a double gives you the exact value (the fraction of 1/24 that means an hour)"); COM.VariantClear(newPData); OS.GlobalFree(newPData); } which leads to the output: 40000.041666666664 06.07.2009 01:00:00 40000.043 --> As you can see, its rounded 40000.041666666664 --> Only a double gives you the exact value (the fraction of 1/24 that means an hour) To lock at my special case (I use automation objects to read from Outlook). Because Variant doesn't support the return of a Date, VT_DATE is internally converted to VT_R4.
(In reply to S. Mair from comment #2) Thanks Stefan for the code snippet. The changes suggested in comment 0 doesn't make any change to the SWT output. Anyways, noticed that the current truncation behavior in SWT Variant class from double to float is standard in Java too. Try below: public static void main(String args[]){ Double d = new Double(42000.041666666664); System.out.println(d.floatValue() + " ---> Gets Truncated"); } Java Output: 42000.043 ---> Gets Truncated Your use case looks duplicate of enhancement request bug 97404, which was partially worked on long back. *** This bug has been marked as a duplicate of bug 97404 ***
I have made a better code sample to illustrate the problem. A few words before. I have prepared my Outlook to have an email in the inbox. The Received Date is 24.06.2014 09:52:00. To check the exact Date I've used MFCMAPI from Microsoft which can be found here: https://mfcmapi.codeplex.com The Received Date is there named as Message Delivery Time. When using the Code-Sample in the Attachment i get the following: VT_R4{41814.496} 24.06.2014 11:54:22 When changing the R4 to R8 in the setData-Method i get the following: VT_R8{41814.49444444444} 24.06.2014 11:52:00 As you can see, the date is then correct (excapt the hours which is a timezone issue) Note that you need Outlook and an Inbox with at least one message to run the attached Sample-Code.
Created attachment 244544 [details] The Sample that extracts the Date of the first Message in the Inbox
By the way, you are absolutely right that the truncation of R8 to R4 is also this way in standard java. This was only a try of me to illustrate, that the Date will not find enough place in the R4.
Unable to run this attached snippet due to Outlook per-requisite... but comment 4 clarifies the problem, targeting for 4.5M1
Change pushed to master: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=dfa0e6e08e78ca3997697d7afcacc5bc1b6607d2
Resolving bug, fix can be found in below & onwards build: http://download.eclipse.org/eclipse/downloads/drops4/N20140705-1700/#SWT
