In my last blog post I wrote
My bugfix isn’t pretty, I must admit. It just defers these changes until the dialog is fully visible. This has the disadvantage the the user will see it popping up at the wrong place first before its position is corrected and the selected directory becomes visible.
David Millington commented on my G+ post:
I haven’t looked at the code to see how the dialog itself is created or shown, but is it possible to either create it invisibly (not shown), position it, then show via ShowWindow or something, or hook its window proc to intercept its initial move message, or set its transparency to 0 and move and then make opaque, or some other hack?
Which got me thinking. Why not indeed try to hide the dialog while it hasn’t been positioned yet and show it once that has happened?
I tried it but it didn’t work: The dialog still became visible before my code could set its position correctly.
After some more debugging it turned out that the problem isn’t actually that the dialog isn’t visible when the BFFM_INITIALIZED message is sent. The problem is, that the dialog changes its size after the BFFM_INITIALIZED message was handled, so setting its position there got it wrong because it calculated it based on the wrong size. So, setting it again was necessary.
But what if I hook the WindowProc (aka subclass the window), wait for the WM_SIZE message being sent and only then set the dialog position?
That seems to be the solution. I have tried it on my Windows 8.1 machine and it worked every single time. Some preliminary code is already in the dzlib svn, but it needs to be polished some more until I can present it here.