That depends on whether each Case in the Select block
returns a proper value individually for its respective window message event exactly as per MSDN. If it does then DefWindowProc may safely stay in any of the two positions. If not then DefWindowProc had better go into Case Else to allow the offending Cases to return more or less safe default zeros directly to the system from such a crooked message pump.
Either way, your tip (or trick) has no practical value without a detailed description of what's going on in each Case of your Select block.
And at any rate you should also understand that the code you painted blue
is not a loop. Unlike GetMessage, PeekMessage does not wait for the messages to come. If there are no messages in the queue, it simply falls through to the end of program. Consequently, you have to place your code in an outer loop that should run until a WM_QUIT message appears in the message queue:
If win <> 0
Do
While PeekMessage(wm, 0, 0, 0, PM_REMOVE) > 0
TranslateMessage(wm)
DispatchMessage(wm)
Wend
InvalidateRect(win, NULL, FALSE) ' NB: this is going to generate WM_PAINT messages like hell
Loop While wm.message <> WM_QUIT
End If