Compatibility vs Unicode support

[fafalone]

I noticed something today that puts tB between a rock and a hard place: breaking large swathes of existing code, or not supporting Unicode.

This comes in the context of ListView control (and also applies at a minimum to the TreeView). While you can send either A or W messages, certain notify messages you receive when subclassing have A and W versions, and only one is sent, according to whether the control responds to WM_NOTIFYFORMAT with NFR_UNICODE or not.

The VB6 controls do not, and send LVN_GETDISPINFOA etc, while the tB controls send LVN_GETDISPINFOW. So obviously there's loads of VB code out there expecting and handling only these ANSI notifications.

This means WinNativeCommonCtls would either need to limit their Unicode support, or not be 100% compatible drop-in replacements. Since this is all documented, standard Common Controls API stuff, I wouldn't consider this an internal implementation detail outside the scope of compatibility, especially given how widespread usage is.

Curious if Wayne has already made a final decision on this, or if not, to gather opinions to help inform that decision.

[bclothier]

Hmm, it sounds like it can be changed at runtime:

A parent window can change the type of structures a common control uses in WM_NOTIFY messages by setting lParam to NF_REQUERY and sending a WM_NOTIFYFORMAT message to the control. This causes the control to send an NF_QUERY form of the WM_NOTIFYFORMAT message to the parent window.

[fafalone]

Indeed it can be, but when the goal is 'run as-is', the default behavior is going to matter. Perhaps there should be an option to enable Unicode notify messages, off by default in imported VB projects, on by default in tB-originated projects?

[WaynePhillipsEA]

Yes, a Boolean property should be all that is needed, I think.