We Keep Coding

How do I use these PostMessage Lparam and Wparam's?

I'm really struggling to understand how PostMessage works. I'm from a web dev background so its all very foreign to me. I'm trying to send a single "a" charcter to a third party application. I've used spy++ to get the PostMessage (params below) required but I cant make sense of how to use the Lparam and Wparam.
This is what I have so far. I'm assuming 00000041 (and the others from spy++) is actually hexadecimal and I'm correct in putting 0x in font of it?
[DllImport("user32.dll")]
[return: MarshalAs(UnmanagedType.Bool)]
static extern bool PostMessage(IntPtr hWnd, uint msg, IntPtr wParam, IntPtr lParam);
const int WM_KEYDOWN = 0x100;
const int WM_KEYUP = 0x101;
const Int32 WM_CHAR = 0x0102;
PostMessage(WindowHandle, WM_KEYDOWN, (IntPtr)(0x00000041), (IntPtr)(0x001E0001));
PostMessage(WindowHandle, WM_CHAR, (IntPtr)(0x00000061), (IntPtr)(0x001E0001));
PostMessage(WindowHandle, WM_KEYUP, (IntPtr)(0x00000041), (IntPtr)(0xC01E0001));
That gives me an algorithmic overflow...
And before anyone tells me to use sendinput this is for a window not in focus :-p

You don't send WM_CHAR, WM_CHAR is synthesized by the application in TranslateMessage - i.e. the application posts it to itself. Either send only the WM_CHAR, or send only WM_KEYDOWN and WM_KEYUP. If sending KEYUP you need to have a delay to allow the application to synthesize the WM_CHAR before you send the KEYDOWN, or they will be processed out of order. Even then you will have a problem with the async key state. However the long and short of it is: You can't synthesize keyboard input using PostMessage.
Here's some background reading:
https://blogs.msdn.microsoft.com/oldnewthing/20130531-00/?p=4203/
https://blogs.msdn.microsoft.com/oldnewthing/20130530-00/?p=4213/
https://msdn.microsoft.com/en-us/library/windows/desktop/ms646276(v=vs.85).aspx
Your best bet is probably to put the application to the foreground and use SendInput.

SendMessage() only working when window is open, not when minimized

I've been using SendMessage to send mouse clicks to a couple of windows. One being a game(everything works perfectly), but the other window, being a 3rd party tool for the game is having trouble with SendMessage. If the window is 'not minimized' everything works fine, don't matter if window is completely covered up by another. But if that same window is minimized then nothing happens, I checked with spy++ and the messages are indeed getting received but not being processed (correct term?). I've tried to solve this last couple days, doing both searches on here and Google alike, many of topics but nothing helped?
//MyImports
[DllImport("user32.dll", CharSet = CharSet.Auto)]
static extern IntPtr SendMessage(IntPtr hWnd, UInt32 Msg, IntPtr wParam, IntPtr lParam);
[DllImport("user32.dll", SetLastError = true)]
static extern IntPtr FindWindow(string lpClassName, string lpWindowName);
And this is how I have it wrapped
public static void LClick(string windowclass, int x, int y)
{
IntPtr WHandle = FindWindow(windowclass, null);
SendMessage(WHandle, (int)WMessages.WM_LBUTTONDOWN, (IntPtr)1, (IntPtr)MakeLParam(x, y));
SendMessage(WHandle, (int)WMessages.WM_LBUTTONUP, (IntPtr)0, (IntPtr)MakeLParam(x, y));
}
I have tried focus, activate. One thing that might be useful info is that the third party program is being loaded as module("Qt5QWindowIcon") of the game.
I tried PostMessage as well, and it does the same thing as SendMessage() same problem when minimized.
This game does allow for macroing and unattended macroing, Hints the third part tool designed to execute the macros (published by the creators) I'm just trying to simulate a mouse click on the program to start the macro.
I would just use SendInput, but the entire purpose of my program is to run in background.

I 've faced same problem .Please change assembly name and project name (Changed name not started with name on that you are throwing/posting windows message)then rebuild it and check it. Now you will able to debug.

Using WH_JOURNALRECORD and cancel does seem to return the WM_CANCELJOURNAL

I'm using C# and I've got the program successfully recording the journal messages using SetWindowsHookEx with WH_JOURNALRECORD.
My problem comes when it's time to stop. The docs show that if the user pressed CTRL-ESC or CTRL-ALT-DELETE a WM_CANCELJOURNAL message will be posted that I can watch to know when to stop. My application gets unhooked but I never seem to get a WM_CANCELJOURNAL.
I have two hooks setup. One hook to do the Journal Record and one to check for the cancel message:
IntPtr hinstance = Marshal.GetHINSTANCE(Assembly.GetExecutingAssembly().GetModules()[0]);
JournalRecordProcedure = JournalRecordProc;
journalHook = SetWindowsHookEx(WH_JOURNALRECORD, JournalRecordProcedure, hinstance, 0);
GetMessageProcedure = GetMessageProc;
messageHook = SetWindowsHookEx(WH_GETMESSAGE, GetMessageProcedure, hinstance, 0);
------
public static int JournalRecordProc(int nCode, IntPtr wParam, IntPtr lParam)
{
if (nCode < 0) return CallNextHookEx(journalHook, nCode, wParam, lParam);
EventMsgStruct msg = (EventMsgStruct) Marshal.PtrToStructure(lParam, typeof (EventMsgStruct));
script.Add(msg); //just a quick way to record for now
return CallNextHookEx(journalHook, nCode, wParam, lParam);
}
public static int GetMessageProc(int code, IntPtr wParam, IntPtr lParam)
{
//it comes here but how do I test if it's WM_CANCELJOURNAL ??
//code always seems to be equal to zero.. I must be missing something
return CallNextHookEx(journalHook, code, wParam, lParam);
}

I suppose you're referring to this section in the documentation:
This role as a signal to stop journal recording means that a CTRL+BREAK key combination cannot itself be recorded. Since the CTRL+C key combination has no such role as a journaling signal, it can be recorded. There are two other key combinations that cannot be recorded: CTRL+ESC and CTRL+ALT+DEL. Those two key combinations cause the system to stop all journaling activities (record or playback), remove all journaling hooks, and post a WM_CANCELJOURNAL message to the journaling application.
The problem is that the WM_CANCELJOURNAL message is not sent to the callback function you installed with SetWindowsHookEx. But unlike other WM_* messages, it is also not meant to be processed by a window procedure (WndProc in WinForms) because it is posted to the message queue of the thread and is not associated with any particular window.
Rather, the documentation advises that one must process it within an application's main loop or using a WH_GETMESSAGE hook:
This message does not return a value. It is meant to be processed from within an application's main loop or a GetMessage hook procedure, not from a window procedure.
[ . . . ]
The WM_CANCELJOURNAL message has a NULL window handle, therefore it cannot be dispatched to a window procedure. There are two ways for an application to see a WM_CANCELJOURNAL message: If the application is running in its own main loop, it must catch the message between its call to GetMessage or PeekMessage and its call to DispatchMessage. If the application is not running in its own main loop, it must set a GetMsgProc hook procedure (through a call to SetWindowsHookEx specifying the WH_GETMESSAGE hook type) that watches for the message.
In managed WinForms code, you obviously don't have any access to or control over the application's main loop. I'm not sure if adding a message filter to your application will let you handle this message or not: I haven't tried it. If it will, that's probably the route you want to take, considering the alternative, which is to install a second hook, WH_GETMESSAGE, and then in that hook procedure, listen for the WM_CANCELJOURNAL message.
Update:
In the GetMessageProc callback function, the code parameter just tells you whether the hook procedure should process the message. Virtually all of the time, it's going to be 0, which is equivalent to the symbolic constant HC_ACTION. If the code parameter is less than 0, the hook procedure should simply call the CallNextHookEx function without performing any further processing. That's basically the exact same thing you did for the JournalRecordProc callback function.
The window message is going to be found in a MSG structure, a pointer to which is passed to the callback function as the lParam parameter. But that's Win32 stuff. Don't mess with raw pointers in .NET, let the P/Invoke marshaler handle all of that dirty stuff for you. The native MSG structure is equivalent to the managed System.Windows.Forms.Message structure (the same thing used by the WndProc method), so if you declare your GetMessageProc callback function like this, things will be much simpler:
public delegate int GetMessageProc(int code, IntPtr wParam, ref Message lParam);
Then, the windows message is found as the Msg member of the Message structure. That's the value you want to compare against WM_CANCELJOURNAL:
public static int GetMessageProc(int code, IntPtr wParam, ref Message lParam)
{
if (code >= 0)
{
if (lParam.Msg == WM_CANCELJOURNAL)
{
// do something
}
}
return CallNextHookEx(messageHook, code, wParam, ref lParam);
}
Note that in order for the above call to CallNextHookEx to work, you'll also have to provide an overloaded definition of the CallNextHookEx function that matches the signature of your GetMessageProc callback function:
[DllImport("user32.dll")]
public static extern int CallNextHookEx(IntPtr hHook, int nCode,
IntPtr wParam, ref Message lParam);

C# Using PostMessage

I'm trying to send a key to an application. I tested the Handlewindow value used breakpoints to understand what I'm doing wirong but i cant find a solution. To be more detailed, its a little game and when I activate the chatbar ingame, the key I want to send will be written there, but I want to make it functionaly when I am playing to use the commands. The game doesnt have a guard or some protections.
Here is my code:
[DllImport("user32.dll")]
static extern bool PostMessage(IntPtr hWnd, uint Msg, int wParam, int lParam);
const uint WM_KEYDOWN = 0x0100;
private void button1_Click(object sender, EventArgs e)
{
string pName = textBox1.Text;
//Get Processes
Process[] processes = Process.GetProcessesByName(pName);
//Main part
foreach (Process p in processes)
if (p.ProcessName == (string)pName)
{
PostMessage(p.MainWindowHandle, WM_KEYDOWN, (int)Keys.W, 0);
}
}
Like I said, it can be sent 1000000 times successfully but nothing happens.
Is there another way how I can send keys to an Windows application that works minimized or even hidden? It should be only send to my app.

If i understand correctly, you want to send keys to a game.
In this case i think that the game is not fetching the keys from the Windows Message queue, it is probably reading the keyboard status directly using DirectX or similar ways.
See this similar question:
Send Key Strokes to Games

You can't fake messages like this and expect it to work reliably - all you are doing is sending a message, nothing fancy.
What this means is that if the target program tests for input in a different way (for example by directly checking the key state, reacting to different messages or just using a completely different mechanism) the target program at best may just completely ignore your input and at worst get totally confused.
Use the SendInput function instead (I'm not sure if this exposed as part of the .Net framework or not).
Some interesting blog articles which are fairly relevant:
You can't simulate keyboard input with PostMessage
Simulating input via WM_CHAR messages may fake out the recipient but it won't fake out the input system

Just note that the correct import of PostMessage is:
[DllImport("user32.dll")]
static extern bool PostMessage(HandleRef hWnd, uint Msg, IntPtr wParam, IntPtr lParam);
Sending the keys like you are doing might not work, but you can use spy++ to capture the actual messages that are being posted to the application by windows and use those.
https://learn.microsoft.com/en-us/visualstudio/debugger/introducing-spy-increment?view=vs-2022

Often programmers will react to KeyUp events rather than down; did you try sending WM_KEYUP?

You should be using SendInput to simulate input into another window.
See this blog post for more details.

SendMessage vs. WndProc

I'm trying to extend TextBox control to add watermarking functionality. The example I've found on CodeProject is using imported SendMessage function.
[DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = false)]
static extern IntPtr SendMessage(IntPtr hWnd, uint Msg, uint wParam, [MarshalAs(UnmanagedType.LPWStr)] string lParam);
void SetWatermark()
{
SendMessage(this.Handle, 0x1501, 0, "Sample");
}
I'm wondering why not use protected WndProc instead
void SetWatermark()
{
var m =new Message() { HWnd = this.Handle, Msg = 0x1501, WParam = (IntPtr)0, LParam = Marshal.StringToHGlobalUni("Sample") };
WndProc(ref m);
}
Both seem to work fine. Almost all examples I've seen on internet use SendMessagefunction. Why is that? Isn't WndProc function designed to replace SendMessage?
P.S. I don't know right to convert string to IntPtr and found that Marshal.StringToHGlobalUni works ok. Is it right function to do this?

WndProc does not replace SendMessage, it is the .NET equivalent of WindowProc. WndProc is called by your application's message pump (which receives messages that are sent or posted by SendMessage or PostMessage) to process them. By calling WndProc directly, you by-pass the special message handling that Windows performs, such as bundling WM_PAINT messages, and can potentially cause some nasty problems where messages appear out of the order that they're expected by windows within your application.
As stated in MSDN,
All messages are sent to the WndProc
method after getting filtered through
the PreProcessMessage method.
The WndProc method corresponds exactly
to the Windows WindowProc function.
For more information about processing
Windows messages, see the WindowProc
function documentation in the MSDN
library at
http://msdn.microsoft.com/library.
By calling it directly, you deprive the system of a chance to perform preprocessing or any other handling of that message. The .NET framework runs on top of Windows and without sending or posting the message, the underlying system cannot do anything with that message, so you lose out on anything the underlying system might do for you.