On Mon Sep 5 10:26:03 2022 +0000, Alexandros Frantzis wrote:
@epo Thanks for the additional investigation, and, yes, I am happy to iterate on the fix. To ensure I have understood this correctly, the proposed plan is: use the contents of CREATESTRUCT.lpszName to differentiate whether the creation is coming from MCIWndCreateA/W, and hence whether we should expect unicode data. Since pointer comparison won't work, we would set the name to some arbitrary string value, unlikely to be used by any application. One aspect that is not clear to me, is whether the current fallback heuristic of checking the unicode state of the parent should be kept. From your investigation:
both CreateWindowEx(A|W) succeed with an ANSI string as lParam (and
fail with Unicode string - that's not included in the testbot, but generate a MCIWNDM_OPENA message (*)) Were you able to check if this behavior holds regardless of the unicode state of the parent?
@afrantzis: yes, I've extended the tests (see merge request !776 for the details), and the fallback is ok according to the tests: when parent (if any) is Unicode, lParam is expected to be Unicode.
perhaps the best way to move forward would be to integrate those tests in your serie