Nothing is drawn in the "WM_INITDIALOG" event (or even "WM_SHOWWINDOW" for that matter), since the window is not yet visible on screen. Also, the DLGPROC callback function does not have the ability to ignore certain messages that we do not want to be processed:

Typically, the dialog box procedure should return TRUE if it processed the message, and FALSE if it did not. If the dialog box procedure returns FALSE, the dialog manager performs the default dialog operation in response to the message.
So either way the message is processed. Subclassing can resolve this shortcoming. I did mention this in post #8 above:

For example the "WM_COMMAND" message can be discarded if the user clicks "OK" when the InputBox is empty and the "RequireInput" property is True!
In order to completely abandon the Microsoft code you would need to stop using the "4031" resource and make a new template from scratch. This way you could completely control the size and position of all "InputBox" elements, as well as including additional buttons, labels, icons, whistles and bells.

However I enjoy reusing existing functionality such as the ability to select the initial starting position of the InputBox or leave it as it is, centered on screen. At the end of the day, it's just an "InputBox" and there are many ways to skin a cat.