> In modules/highgui/src/window_w32.cpp:
>
> > @@ -1789,6 +1868,11 @@ static LRESULT CALLBACK HGToolbarProc( HWND hwnd, UINT uMsg, WPARAM wParam, LPAR
> >                          is_processed = 1;
> >                          return (int)(message.wParam << 16);
> >                      }
> > +
> > +                    // Intercept Ctrl+C for copy to clipboard
> > +                    if ('C' == message.wParam && (::GetKeyState(VK_CONTROL)>>15))
> > +                        ::PostMessage(message.hwnd, WM_COPY, 0, 0);
>
> This seems like a rather roundabout way of doing it. Why not do the copy
> either right here, or in a WM_KEYDOWN handler in MainWindowProc?
>
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.
The thing is that not every key-stroke (combination) actually gets to
MainWindowProc.

Also this way waitKey() can return immediately while the copy is done via
the Windows message queue.

Moreover, the documentation for WM_COPY says it's to be used with edit
> controls or combo boxes, and while I don't think it makes this use an
> error, it's still questionable.
>
Indeed, but why define a new message value when there is one already
available to say the same thing.
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.