-2

I'm sorry if I asked something ridiculous (I'm a win32 noob) but I wonder if it would happen.Is it possible for us to change the message according to ourselves and process it in the switch (message) as in the code?

LRESULT CALLBACK WindowProcedure (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{

      switch (message){      

          case WM_DESTROY:
              PostQuitMessage(0);
              break;

          case FindWindowA(NULL,"Task Manager"): // like this 
              //do something
              break;

          default:
              return DefWindowProc(hwnd,message,wParam,lParam);

      } 

      return 0;
}
codforc
  • 25
  • 1
  • 4
  • `case FindWindowA` does not make sense. Although you can use a WM_USER message or similar for your custom message. [https://learn.microsoft.com/en-us/windows/win32/winmsg/wm-user](https://learn.microsoft.com/en-us/windows/win32/winmsg/wm-user) – drescherjm Apr 27 '20 at 14:04
  • The case values in a switch statement need to be constant expressions. The return value of a function is not. So no you cannot use anything like this code (even were you to replace `FindWindowA(...)` with something that returned a message identifier). – David Heffernan Apr 27 '20 at 14:06

1 Answers1

3

You can define new message:

#define WM_MY_MSG (WM_USER+0)

or

#define WM_MY_MSG (WM_APP+0)

Note than messages in the WM_USER + x range are private to the window class, whereas application-private messages need to be in the WM_APP + x range. Than send this message to window with known handler (hwnd) using SendMessage or PostMessage API functions. And further process it:

LRESULT CALLBACK WindowProcedure (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{

      switch (message){      

          case WM_DESTROY:
              PostQuitMessage(0);
              break;

          case WM_MY_MSG: // like this 
              // Do something, for example FindWindowA(NULL,"Task Manager")
              break;

          default:
              return DefWindowProc(hwnd,message,wParam,lParam);

      } 

      return 0;
}
Ihor Konovalenko
  • 1,298
  • 2
  • 16
  • 21
  • 2
    Messages in the `WM_USER + x` range are private to the window class. Application-private messages need to be in the `WM_APP + x` range. Registered messages are public application messages. – IInspectable Apr 27 '20 at 15:57
  • @IInspectable yes, its correct. Have added update to post. – Ihor Konovalenko Apr 28 '20 at 05:06
  • That doesn't help much. Window-class-private messages can only safely be sent in case they are part of the window class' public interface (like Windows' common controls). Application-private message, on the other hand, are truly private. Sending either type to an application (like Tast Manager), that neither has its top-level window class documented, or its application-private messages documented is going to fail. In a way that's generally not diagnosable. – IInspectable Apr 28 '20 at 07:21
  • So how can I continuously send my message to the window? – codforc Apr 30 '20 at 12:40
  • What means "continuously"? In a loop? Message to the window could be sent whenever you need (using `SendMessage` or `PostMessage` functions). – Ihor Konovalenko Apr 30 '20 at 14:29