wxWidgets is always build in UNICODE using the WIDE win32 API functions. But applications using it might be built without UNICODE, using the ANSI win32 functions.
Right now wxWidgets #undefs some of the win32 API functions and defines them as inline functions using the WIDE win32 API. Making these unavailable for applications that want to use the ANSI versions later.
Fix this by inlining the functions as WIDE only when UNICODE was already defined, not when wxWidgets defines it themselves in platform.h.
See #25803
cc @jamarr81 would this work?
https://github.com/wxWidgets/wxWidgets/pull/25965
(10 files)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@MaartenBent pushed 1 commit.
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@vadz commented on this pull request.
Thanks, I think this should work and I can't think of anything else that this would break, but I'd prefer to condense all the wrapper definitions using a helper macro before merging this.
> + #if wxUSE_UNICODE_WINDOWS_H
return CreateDialogW(hInstance, pTemplate, hwndParent, pDlgProc);
+ #else
+ return CreateDialogA(hInstance, pTemplate, hwndParent, pDlgProc);
+ #endif
Could we just define our own wxFUNC_AW() macro once, depending on wxUSE_UNICODE_WINDOWS_H value, and then replace all these fragments with just
- #if wxUSE_UNICODE_WINDOWS_H - return CreateDialogW(hInstance, pTemplate, hwndParent, pDlgProc); - #else - return CreateDialogA(hInstance, pTemplate, hwndParent, pDlgProc); - #endif + return wxFUNC_AW(CreateDialog)(hInstance, pTemplate, hwndParent, pDlgProc);
?
> + #define wxLPCTSTR LPCWSTR + #define wxLPSTR LPWSTR + #define wxLPWNDCLASS LPWNDCLASSW + #define wxDOCINFO DOCINFOW + #define wxLPFINDREPLACE LPFINDREPLACEW
Minor, but these could be typedefs (or even using) if we try to minimize the use of preprocessor (possibly not really helpful in this header...).
> // // This looks quite ugly here but allows us to write clear (and correct!) code // elsewhere because the functions, unlike the macros, respect the scope
@MaartenBent pushed 2 commits.
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@MaartenBent commented on this pull request.
> + #define wxLPCTSTR LPCWSTR + #define wxLPSTR LPWSTR + #define wxLPWNDCLASS LPWNDCLASSW + #define wxDOCINFO DOCINFOW + #define wxLPFINDREPLACE LPFINDREPLACEW
typedef/using doesn't work when these types are not defined. Apparent in the non-PCH builds.
This can happen for example when winundef.h is included but windows.h is not, like in wrapcdlg.h or ioswrap.h or iosfwrap.h.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@MaartenBent pushed 1 commit.
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Not sure how to fix these last errors in CI. In this case UNICODE is not defined by the build system / user. So wxWidgets defines is. Then windows.h is included (with UNICODE defined), resulting in TEXT and other defines/macros becoming the WIDE variant.
But later in the application code, after winundef.h, the ANSI variants will be used. But TEXT is still the WIDE variant.
I think I'll just let it default to the WIDE variant, unless the application defines wxWIN32_UNDEF_AS_ANSI before including wx headers:
#if defined(WXBUILDING) || !defined(wxWIN32_UNDEF_AS_ANSI) // wide #else // ansi #endif
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
We could define something (_UNICODE?) in the sample to work around this problem there but it seems indeed safer and better to require predefining some symbol if you really need A versions of the API. But arguably, wxNO_WIN32_WIDE_FUNCTIONS (or just wxNO_WIN32_W) would be more in line with our preprocessor symbol naming conventions.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@MaartenBent pushed 4 commits.
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@MaartenBent @vadz tysm for following up on this! I haven't had a chance to revisit it; however, these changes look good to me on paper.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@MaartenBent pushed 2 commits.
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@vadz approved this pull request.
Looks good, thanks!
It would be great if this could be tested in some application which needed this, but if nobody does it soon, I'll just merge this and hope that it works for them.
> @@ -847,13 +847,13 @@ class ClassRegistrar
bool IsRegistered() const { return m_registered == 1; }
// try to register the class if not done yet, return true on success
- bool Register(const WNDCLASS& wc)
+ bool Register(const WNDCLASSW& wc)
It would be good to add a test for compiling this file with wxNO_WIN32_W to at least one MSW CI job to catch any errors that could be introduced into it later by forgetting to explicitly use W symbol versions.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()