Use DefWindowProcW in win32 examples

[markreidvfx]

The current win32 examples will truncate the window title if you try to modify it with Platform_SetWindowTitle.

Before

After

It took me a while to figure out it was because the examples are using DefWindowProc instead DefWindowProcW.
The issue is setWindowTextW sends a WM_SETTEXT message to WndProc and gets interpreted as ascii.
Maybe this fix will help others from having to debug this issue when they are getting started using the examples :)

[ocornut]

Hello,

Thanks for the PR but this needs clarification.
It is custom and considered correct to call win32 functions without the A/W suffix, the selection is done based on your compile-time UNICODE settings.

Please clarify how you are compiling the examples and what to do to repro said issue. (So i can confirm it locally).

thanks!

[markreidvfx]

Oh, your right, now I see the /D UNICODE in the bat files, my build script wasn't doing that. Neverminded then, sorry to waste your time, I'll drop this pull request.

[ocornut]

I am still interested in this.
Can you clarify what you were doing to trigger the issue, even without building with UNICODE ?

[markreidvfx]

In the docking branch, if your remove /D UNICODE /D _UNICODE from any of the win32_directx bat files

Add to this main loop

ImGuiViewport* viewport = ImGui::GetMainViewport();
ImGui::GetPlatformIO().Platform_SetWindowTitle(viewport, "Dynamic Title");

You get the behavior I was getting.

[nicolasnoble]

9 chances out of 10 the string was still getting converted to full unicode before passed to DefWindowProc, which would then have been tied to DefWindowProcA, and stopped at the first '\0' from the unicode conversion of Dynamic.

[markreidvfx]

@nicolasnoble yes, without the complier defs, ImGui_ImplWin32_SetWindowTitle converts the string to uft16 with MultiByteToWideChar , calls SetWindowTextW and the utf16 string gets passed to DefWindowProcA

[nicolasnoble]

Yep, that's the wrong codepath :) We shouldn't call SetWindowTextW on non-unicode builds at all. The right PR would be (1) call SetWindowText instead of SetWindowTextW, and (2) have an #if defined(UNICODE) || defined(_UNICODE) before calling SetWindowText to decide whether or not to convert the input string to unicode.

ASCII software will simply misbehave if passed a non-ASCII UTF-8 string, but there's little to do in this case...

[ocornut]

While #5975 is not as evident because it is a demo app, we should definitively make the multi-viewport backend behave with applications not compiled with /D UNICODE.

Strangely with that setup, ImGui_ImplWin32_SetWindowTitle() works on secondary viewports but not the main viewport created by the example. Investigating the difference now.

[ocornut]

My apologies for misunderstanding this the first round. I have now merged your PR as fe0a24f
Thank you!