Ilya Shpigor wrote:
Or course you can, format a string every time contents change and store it with SetWindowText(). WM_GETTEXT will work through default procedure (I've done it that way for IPAddress control).
This is good idea, but SetWindowText just send the WM_SETTEXT message. Your patch "comctl32/datetime: Block WM_SETTEXT message" don't allow to do it.
Ah, forgot about it, sorry. Now I think your way is good enough, maybe WM_SETTEXT is still forwarded to default procedure and WM_GETTEXT not, I don't know.
Anyway GetWindowText should work, and Wine's implementation uses WM_GETTEXT only for same process windows, so you shouldn't override default handling for this message.
This possible to test: is the datetime window procedure process WM_GETTEXT? This message must be send to control directly and be processed through CallWindowProc with DefWindowProc parameter. Is this test give right results?
It's possible but such test will tell nothing, WM_GETTEXT definitely works for this control class and returns current content. Blocked WM_SETTEXT makes me think that WM_GETTEXT is overridden as you've done.
To test that you could subclass control, catch WM_GETTEXT in subclass proc and forward it to default procedure directly bypassing control handling. If it returns nothing or some creation time passed text then your patch is ok.
All of that comes to be extra testing not related to directly visible control behavior, treat this as additional checks.