[FA] GPGNet TD Tool - not recognizing user32.dll commands?

Hi all,
Hopefully this is the right subforum for this topic. It's not directly related to SupCom modding, but rather GPGNet "modding". From everything I've read it seems directly related to how GPGNet processes keyboard input, so I figured this would be the best place to hopefully get some answers. :)
The Tournament Director Tool that the TDs use has several limitations (most notably the difficulty in editing "speech" text), and since I'm always up for fun little side projects like this I offered to write a replacement.
I have a basic C# Windows Forms app created that replicates the TD tool's functionality (and improves upon it), but it has one glaring flaw - I cannot seem to programmatically send text to the chat box in GPGNet.
First, I already have the window handle to the chat text entry box. This was the relatively easy part, by using Spy++ to determine the class name of the chat box and, get a reference to the Process of GPGNet by searching for it's name, and recursively searching it's child windows until finding the one that matches the chat box's class name. I then use SetForegroundWindow() to bring it to the front.
Note that I am interoping with the user32 DLL to accomplish this. I know that this part works, as immediately after that code is run the GPGNet window is set in focus and I can start typing away in the chat box.
After that, I thought it would be trivial to send a message to the text box window to paste in the current "speech" text. However, GPGNet seems to be completely immune to every form of keyboard input simulation I've tried. Briefly, the solutions I've tried are:
1) Using the C# SendKeys.Send() and .SendWait() commands. This has no effect.
2) Using the user32 SendMessage, PostMessage, and SendInput commands. No effect.
3) Fearing that maybe an error in the way I'm interoping was causing this, I tried several open source keyboard simulation libraries (most notably http://inputsimulator.codeplex.com/). Still nothing.
Also note that I'm fairly certain it isn't my code that is causing this, as I can successfully send messages using the above techniques to Notepad, Word, and even the Visual Studio IDE. This leads me to believe that there is some special logic built into GPGNet to prevent keyboard simulation (why, I have no idea). But two pieces of information contradict this - 1, the previous TD tool does this, and 2, keyboard macros (eg, AutoHotkey scripts or macros recorded into my Logitech keyboard) work just fine in GPGNet (which I assume also use similar Windows APIs to simulate keyboard input).

Any suggestions? Or better yet, anyone who knows the inner workings of GPGNet that can point me in the right direction? :)
Thanks!|||They could be using RawInput, and sending a WM_CHAR message won't trigger RawInput messages. It's a bit silly to use RI for the keyboard, but hey. It's also possible that they expose their own API function for inserting keyboard input.|||So... was my suggestion of any help, or what?|||Thanks for the suggestion DeadMG - I think that's the most plausible explanation so far.
Just had some more time to work on this:
1) I was incorrect in my earlier assessment - AutoHotkey does *not* seem to work in chat. I had hoped to create a script to paste the contents of the clipboard and execute that instead of trying to do it from C#, but that doesn't seem possible.
2) Since keyboard macros *do* work, I'm leaning towards the raw input being the stopping block here.
I've been unable to find any information for simulating raw input... and I can't get ahold of the author of the original tool's author so I'm not sure how he did it. I suppose it's possible that there's some type of public API, but I can't find any mention of it, anywhere.
Any suggestions?|||You can post WM_INPUT messages. RawInput is just processed by the message loop as per any other form of input, the structure is just different. If you look up the documentation on reading RawInput, it should tell you all you need to know to post it.|||DeadMG|||I'm pretty sure that PostMessage will post whatever message you ask it to post.|||Apologies for the late replay!
DeadMG|||You will have to use Microsoft's Detours library and hook GetRawInputData. As the lParam of WM_INPUT is passed straight in, you should be able to do whatever custom logic you need here.