http://bugs.winehq.org/show_bug.cgi?id=6533
------- Additional Comments From focht@gmx.net 2007-09-05 06:12 ------- Hello,
it's a german application running on english locale, emitting interesting shortcoming on wine.
It first constructs a date string:
--- snip --- 0018:Call KERNEL32.GetLocalTime(0034e5f8) ret=660e8d83 0018:Ret KERNEL32.GetLocalTime() retval=00000001 ret=660e8d83 0018:Call oleaut32.VarDateFromUdate(0034e61c,00000000,0034e5f8) ret=660e8d06 trace:variant:VarDateFromUdateEx (0x34e61c->5/9/2007 12:9:59:26128 3 27872,0x00000409,0x00000000,0x34e5f8) trace:variant:VARIANT_RollUdate Raw date: 9/5/2007 12:9:59 trace:variant:VARIANT_RollUdate Rolled date: 9/5/2007 12:9:59 trace:variant:VarDateFromUdateEx Returning 39211.5 ... trace:variant:VarFormat (0x34e7b0->(VT_DATE),L"dd.mm.yyyy",1,1,0x00000000,0x34e640) trace:variant:VARIANT_FormatDate (0x34e7b0->(VT_DATE),L"dd.mm.yyyy",0x34e46c,0x00000000,0x34e640,0x00000400) trace:variant:VariantChangeTypeEx (0x34e3e0->(VT_EMPTY),0x34e7b0->(VT_DATE),0x00000409,0x0000,VT_DATE) ... trace:variant:VariantChangeTypeEx returning 0x00000000, 0x34e3e0->(VT_DATE) trace:variant:VarUdateFromDate (39211.5,0x00000000,0x34e3b8) ... trace:variant:VARIANT_FormatDate buff is L"09.05.2007" ... trace:variant:VarFormat returning 0x00000000, L"09.05.2007" 0018:Ret oleaut32.VarFormat() retval=00000000 ret=660f587b --- snip ---
Notice the supplied L"dd.mm.yyyy" format string. It's a german date string (hard coded into VB binary).
A bit later ...
--- snip --- 0018:Call oleaut32.VariantChangeTypeEx(0034e5c8,0058b168,00000400,00000002,00000007) ret=660e0be6 trace:variant:VariantChangeTypeEx (0x34e5c8->(VT_NULL),0x58b168->(VT_BSTR),0x00000400,0x0002,VT_DATE) ... trace:variant:VarDateFromStr (L"09.05.2007",0x00000400,0x00000000,0x34e488) 0018:Call KERNEL32.GetLocaleInfoW(00000400,20000021,0034e3c8,00000002) ret=6047e6f2 trace:nls:GetLocaleInfoW (lcid=0x409,lctype=0x21,0x34e3c8,2) 0018:Ret KERNEL32.GetLocaleInfoW() retval=00000002 ret=6047e6f2 trace:variant:VarDateFromStr iDate is 0 0018:Call KERNEL32.GetLocaleInfoW(00000400,00000038,0034e1d8,00000080) ret=6047e766 trace:nls:GetLocaleInfoW (lcid=0x409,lctype=0x38,0x34e1d8,128) trace:nls:GetLocaleInfoW (lcid=0x409,lctype=0x38,0x34e1d8,128) returning 8 L"January" ... trace:variant:VarDateFromStr 0x00000003 ... trace:variant:VariantChangeTypeEx returning 0x80020005, 0x34e5c8->(VT_NULL) 0018:Ret oleaut32.VariantChangeTypeEx() retval=80020005 ret=660e0be6 ... 0018:Call user32.LoadStringA(66000000,00002717,0034e184,000001f4) ret=660d9e18 trace:nls:WideCharToMultiByte cp 0 L"Type mismatch" -> "Type mismatch", ret = 13 --- snip ---
Now the date string shall be converted to date using current locale, which is system default, sublang eng -> 0x409 on my system.
When the date string is parsed, the delimiters are being taken as DP_TIMESEP type flags. After parsing it tries to fill system time struct data by evaluating parsed date struct data/flags. It encounters inconsistency (because the parse data doesnt match expected time fields) therefore DISP_E_TYPEMISMATCH is returned.
Now one can argue if we set locale to german (LANG/LC_TYPE to de_DE) this might work. No it does not. VarDateFromStr() doesnt take locale into account when processing date/time delimiters - they are hard coded.
Compare delimiters:
Locale Common format Long format Short format ---------------------------------------------------------------------- United States English 05/09/07 April 9, 2007 05/09/07 German 9.5.07 9. April 2007 09.05.07
With locale set to en_EN this error is acceptable, because the application used hard coded date format string on wrong locale. With locale set to de_DE this is a wine problem/bug, because "." is a valid date delimiter.
Regards
-
Wine Bugs