C# FindWindowEx Obtain parameter for lpszClass variable by WinSpy++ not work

Question

enter image description here

PROBLEM

This is my function to send key stroke in background.

class SendMessage
{

[DllImport("user32.dll")]
public static extern IntPtr PostMessage(IntPtr hWnd, uint Msg, IntPtr wParam, IntPtr lParam);
[DllImport("user32.dll", SetLastError = true)]
public static extern IntPtr FindWindow(string lpClassName, string lpWindowName);
[DllImport("user32.dll", SetLastError = true)]
public static extern IntPtr FindWindowEx(IntPtr hwndParent, IntPtr hwndChildAfter, string lpszClass, string lpszWindow);

public static void sendKeystroke(string appName)
{
    const int WM_KEYDOWN = 0x100; 
    IntPtr hWnd = FindWindow(null, appName);
    IntPtr editx = FindWindowEx(hWnd, IntPtr.Zero, "edit", null);
    PostMessage(editx, WM_KEYDOWN, (IntPtr)Keys.A, (IntPtr)0);  
}

}

This code is work fine for notepad for example let appName = "notepad".

However, I can manage to do it in other application ..I practice doing on LINE application.

As you can see in the picture lpszClass variable = "edit" (small red circle) is for notepad.

I need to find it for LINE app so, I use WinSpy++ to capture those class name.

I found out that its class name is "ATL:00B53BE8" (big red circle) which I can type the message

in WinSpy++ and enter, it will appear to Line textbox (blue circle).

IN CONCLUSION

I try to replace capture class name with "edit" but no hope.

I don't understand why capture class name is not usable please help or give me some hint.

I don't know maybe it is about the hierarchy of system application different or not (pink one)

and I don't know which params in FindWindowEx mean that much.

My ultimate goal is to sent key stroke to other application without focus on them.

What is your question? And as is so often the case here, input faking is done with SendInput, and automation with UIAutomation. Why are you hacking like this? — David Heffernan, Sep 08 '14 at 06:35
Hacking ??? I just want to pass input in the background and find out some solution and this seem to work that all — Jongz Puangput, Sep 08 '14 at 06:45
You are hacking. Why don't you use the preferred solutions that I outlined? — David Heffernan, Sep 08 '14 at 06:48
because it can't send key without focus that is what I have know about it. so that is doesn't meet my requirement I want to do other window while let it work (send key) to other app in the background. — Jongz Puangput, Sep 08 '14 at 06:54
So use automation rather than hacking. Anyway, I still can't see a question. What is your question? — David Heffernan, Sep 08 '14 at 06:59
...ahhh what wrong with these methods anyway? hacking? it depend on how I use. and the Question is I want to make this methods work to other application not notepad only as many people provide this as example to send key stroke in background — Jongz Puangput, Sep 08 '14 at 07:06
or else you can tell me how can I get parameters for FindWindowEx — Jongz Puangput, Sep 08 '14 at 07:09
You should use UIAutomation. It can produce a tree structure representing the GUI. FindWindowEx is well documented. You'd need multiple calls to walk through parent child hierarchy. But hacking like that isn't the way forward, not that I expect you, like so many before you, to accept that advice. — David Heffernan, Sep 08 '14 at 07:18
@david heffernan so you mean hack because I use winspy right? — Jongz Puangput, Sep 08 '14 at 07:23
No. The way you attempt to fake the input is hacking. The question still doesn't ask a clear question. A general goal is not a question. — David Heffernan, Sep 08 '14 at 07:28
I can make it work anyway because of this discussion thx thx again. actually I still not clear between hack and not hack because I use winApi? however, I will consider your mention and find alternative instead what I'm doing. — Jongz Puangput, Sep 08 '14 at 07:41

score 1 · Answer 1 · edited Sep 08 '14 at 07:45

You cannot expect WM_KEYDOWN messages sent to applications that do not have the focus to have the desired effect. it is simply not supported. Receiving a WM_KEYDOWN message implies, by the rules of Windows, that your application has the focus. Only focused applications can get keyboard input.

So what you are trying might work in certain cases, but it is not guaranteed to work. The application may make the quite-reasonable assumption that it has the focus if it is receiving keyboard input.

If it "works" in Notepad, it is because Notepad is a very ~~dumb~~ simple application. It is just an edit control with a menu bar. Its handling of the WM_KEYDOWN message likely amounts to no more than adding the character represented by the key indicated by the message parameters to the edit control. Most other applications are more complicated. And even Notepad isn't guaranteed to work in all cases. For example, when its window is minimized. There are plenty of reports of problems like this elsewhere on this site and the Interwebz.

To put it simply: sending WM_KEYDOWN and its friends are not the way that you simulate keyboard input in Windows. There are two basic ways of doing it. The first is to use the SendInput function; the other is to install a WH_JOURNALPLAYBACK hook. Both of these tacks have been variously taken by different versions of the implementation for the SendKeys class in .NET. Both of them send the synthesized input to the focused window because, in Windows, that is the window that receives all input.

If this is to work at all, you absolutely must find another way of doing it. In the comments, David has suggested to use UI Automation, a tool designed for this purpose. It is conveniently wrapped by the .NET Framework. It is unclear why you are resisting this advice. With UI Automation, you can navigate easily through the hierarchy of windows in an application, using a nested tree structure. This tree is built automatically from all of the window handles in the process. This allows you to easily find the control(s) you want to manipulate. Then, you obtain the appropriate control patterns, and perform whatever action you want.

score 0 · Answer 2 · answered Sep 08 '14 at 07:48

From Discussion with David Herffernan

"You'd need multiple calls to walk through parent child hierarchy"

Now, I can make my code work.. However, it seem this isn't the right way to do (Hacking)

but, I want to answer this question for my reference

the key is use of FindWindowEx it work as David Herffernan said.

Instead of this..

public static void sendKeystroke(string appName)
{
    const int WM_KEYDOWN = 0x100; 
    IntPtr hWnd = FindWindow(null, appName);
    IntPtr editx = FindWindowEx(hWnd, IntPtr.Zero, "edit", null);
    PostMessage(editx, WM_KEYDOWN, (IntPtr)Keys.A, (IntPtr)0);  
}

I edit to this..

public static void sendKeystroke(string appName)
{
    const int WM_KEYDOWN = 0x100; 
    IntPtr hWnd = FindWindow(null, appName);
    IntPtr editx1 = FindWindowEx(hWnd, IntPtr.Zero, "SkinScrollWnd", null);
    IntPtr editx2 = FindWindowEx(editx1, IntPtr.Zero, "SkinScrollMidWnd", null);
    IntPtr editx3 = FindWindowEx(editx2, IntPtr.Zero, "ATL:00B53BE8", null);
    PostMessage(editx3, WM_KEYDOWN, (IntPtr)Keys.A, (IntPtr)0);  
}

C# FindWindowEx Obtain parameter for lpszClass variable by WinSpy++ not work

2 Answers2

Linked