SWT was dealing with VT_BSTR incorrectly. When marshaling a VT_BSTR from raw system memory into the Variant object, SWT was changing the VT_BSTR to a VT_EMPTY in cases where the data pointer was null. In fact, this in not correct according to COM rules. A VT_BSTR with a null data pointer should be treated as an empty string (""), not an empty variant (undefined).
I didn't know this myself, but I found a blog article on this from 2003 that goes into the nuances of BSTRs.
http://blogs.msdn.com/ericlippert/archive/2003/09/12/52976.aspx
Found by: jluis.barrera
Review by: jat (postmortem)
git-svn-id: https://google-web-toolkit.googlecode.com/svn/trunk@1206 8db76d5a-ed1c-0410-87a9-c151d255dfc7
diff --git a/dev/windows/src/org/eclipse/swt/ole/win32/Variant.java b/dev/windows/src/org/eclipse/swt/ole/win32/Variant.java
index 3ddd0bf..eaccdf3 100644
--- a/dev/windows/src/org/eclipse/swt/ole/win32/Variant.java
+++ b/dev/windows/src/org/eclipse/swt/ole/win32/Variant.java
@@ -1002,7 +1002,8 @@
int[] hMem = new int[1];
OS.MoveMemory(hMem, pData + 8, 4);
if (hMem[0] == 0) {
- type = COM.VT_EMPTY;
+ // A VT_BSTR with a null pointer is equivalent to an empty string
+ stringData = ""; //$NON-NLS-1$
break;
}
// Get the size of the string from the OS - the size is expressed in number
