> That's true, but the whole code is kind-of roundabout. I don't really understand why there are 2, or even 3 (if you count cvWaitKey), proc functions and message handlers.

One of them is for the top-level window; the other is for the child window that actually displays the image. `cvWaitKey` handles certain messages itself, because it has to return when a key has been pressed.

> The thing is that not every key-stroke (combination) actually gets to MainWindowProc.

Are you saying that Ctrl+C doesn't? It seems like it would be dispatched by the `default:` branch below.

> Also this way waitKey() can return immediately while the copy is done via the Windows message queue.

Does it take a sizeable amount of time? And why would it return immediately anyway? This branch doesn't break out of the message loop.

> Indeed, but why define a new message value when there is one already available to say the same thing.

Why use an additional message at all? It seems like `WM_KEYDOWN` is more than enough.

> If ever it will be deemed important to add a menu, it will still be able to use the same WM_COPY, or the one I used can be replaced with a custom value.

Not really following you, but it seems like one could simply use a function.