2

I have a program which has two windows, one for displaying graphics (call this the "graphics window"), the other for entering and displaying text (call this the "text window"). The text window is a child of the graphics window. The program processes keystrokes correctly so long as the text window is highlighted, but if the graphics window is highlighted, the keystrokes are ignored. What I want to do is to arrange for the text window to processes keystrokes even if the graphics window is highlighted.

problem solved:

The text window is itself the parent of a rich edit window.

Inside the graphics window's message handler I have added:

case WM_CHAR: 
case WM_KEYDOWN: 
case WM_KEYUP: 
case WM_SYSKEYDOWN:
case WM_SYSKEYUP: 
    SendMessage(handle_of_rich_edit_window, message, wParam, lParam);
    break;

I had previously tried sending the messages to the text window, but this appeared not to work (I have no idea why). Sending the messages directly to the richedit window seemed to do the trick.

Mick
  • 8,284
  • 22
  • 81
  • 173
  • Windows sends keystrokes to the window with the focus, so both windows procedures will have to handle keyboard input. Like AcidJunkie said, the easiest way to do that is to build a common handler. – Carey Gregory Nov 09 '15 at 15:42
  • @carey gregory: There are large complex handlers already coded up, it would be a nightmare to combine them into one. – Mick Nov 09 '15 at 15:49
  • Then forward the keystrokes from one window to the other. – Carey Gregory Nov 09 '15 at 15:54

2 Answers2

0

Either route the keystrokes of each window to a common handler or use a the low level window hook SetWindowsHookExAPI of Win32

AcidJunkie
  • 1,878
  • 18
  • 21
0

If you have access to every source code in both windows, then simply implement a common handler for the WM messages that apply. However, it sounds like you are for some reason not able to do this(?).

For every Window that can receive messages, you could implement subclassing.

This means that you replace the standard Wndproc message handler of your window with a custom one. In this custom handler, you can decide which messages you wish to treat differently. And for all those messages that you don't wish to treat differently, you call the default Wndproc.

This allows you to either "overload" the default behavior of a window, or to add extra functionality upon a certain event and then afterwards execute the default behavior. It is especially handy if you don't have access to the source code for the Wndproc itself (for example when working with a RAD tool).

So for your specific case, you could subclass each window, grab the messages you are interested in, then call a common handler.

Lundin
  • 195,001
  • 40
  • 254
  • 396