Re: kernel32: Add LCMapStringEx implementation and test it reusing tests from LCMapStringW
André Hentschel nerv@dawncrow.de wrote:
+/* Locale name special values */ +#define LOCALE_NAME_INVARIANT L"" +#define LOCALE_NAME_MAX_LENGTH 85 +#define LOCALE_NAME_SYSTEM_DEFAULT L"!sys-default-locale" +#define LOCALE_NAME_USER_DEFAULT NULL
Have a look how unicode constants are defined in other header files, the above version can't work in Wine.
Also just duplicating LCMapString tests is not a very good idea, it would be better to find a way to share the test data.
Am 30.01.2012 06:16, schrieb Dmitry Timoshkov:
André Hentschel nerv@dawncrow.de wrote:
+/* Locale name special values */ +#define LOCALE_NAME_INVARIANT L"" +#define LOCALE_NAME_MAX_LENGTH 85 +#define LOCALE_NAME_SYSTEM_DEFAULT L"!sys-default-locale" +#define LOCALE_NAME_USER_DEFAULT NULL
Have a look how unicode constants are defined in other header files, the above version can't work in Wine.
true, missed that
Also just duplicating LCMapString tests is not a very good idea, it would be better to find a way to share the test data.
that's not that easy as the parameter count is different, i would need to use macros and i dislike that idea.
André Hentschel nerv@dawncrow.de wrote:
Also just duplicating LCMapString tests is not a very good idea, it would be better to find a way to share the test data.
that's not that easy as the parameter count is different, i would need to use macros and i dislike that idea.
Since you are forwarding LCMapStringEx to LCMapString anyway I'd assume that their behaviour is mostly identical, and if you make a table with tested API parameters, and lcid as a DWORD in the table, then using LCIDToLocaleName to call LCMapStringEx instead of LCMapString sounds feasable.
-
André Hentschel -
Dmitry Timoshkov