[FeatureRequest] Sanderling.KeyboardPress(VirtualKeyCode Key) brings window to front about sanderling

[ALERTua]

i have succeeded with:

const int WM_KEYDOWN = 0x100;
const int WM_KEYUP = 0x101;

[DllImport("User32.dll")]
public static extern Int32 FindWindow(String lpClassName, String lpWindowName);

[DllImport("user32.dll")]
public static extern IntPtr PostMessage(IntPtr hWnd, uint Msg, IntPtr wParam, IntPtr lParam);

int window = FindWindow("triuiScreen", null);
//i don't know how can i get the title of Sanderling Host client window, so this the title is null for now

void key(WindowsInput.Native.VirtualKeyCode keycode)
{
PostMessage((IntPtr)window, WM_KEYDOWN, (IntPtr)(keycode), (IntPtr)0);
Host.Delay(50);
PostMessage((IntPtr)window, WM_KEYUP, (IntPtr)(keycode), (IntPtr)0);
}

//and finally
key(VirtualKeyCode.F10);

also, can you show me an example of how can I use System.Speech.Synthesis.SpeechSynthesizer class? i would like to be announced of local chat changes ;)

[ALERTua]

it would be nice to leave separate keyUP and keyDOWN mechanics for users to manage key modifiers. maybe someone needs holding a key for a long time.
for example, my autopilot has no mouse input, just:

key(VirtualKeyCode.SPACE); //focus on overview
for( int a = 1; a < 20; a = a + 1 )
key(VirtualKeyCode.UP); //this can be replaced with holding down up arrow

key(VirtualKeyCode.VK_D); //warp|dock

of course, this needs to sort overview by icon. yellow one will always be on top.

[Arcitectus]

As title says, Sanderling.KeyboardPress(VirtualKeyCode Key) brings window to front. It would be very nice if this will send keystrokes to client window that is in background without focusing on it. Same with mouse.

Yes, that would be nice. I am interested to see how this could be implemented.

how can I use WinAPI in Sanderling?

The same way as in other .NET applications.
Below is an example of how to call a WinAPI function from the script IDE:

using System.Runtime.InteropServices;
[DllImport("user32.dll")]
[return: MarshalAs(UnmanagedType.Bool)]
static extern bool MessageBeep(uint uType);
MessageBeep(0);

[Arcitectus]

void key(WindowsInput.Native.VirtualKeyCode keycode)
{
PostMessage((IntPtr)window, WM_KEYDOWN, (IntPtr)(keycode), (IntPtr)0);
Host.Delay(50);
PostMessage((IntPtr)window, WM_KEYUP, (IntPtr)(keycode), (IntPtr)0);
}

I understand this covers the case of simulating a single (not combined with others) keyboard key press.

Would you benefit from an additional KeyboardPressViaPostMessage(VirtualKeyCode key) method to wrap this?

[Arcitectus]

I made the changes required to support the mentioned uses.
This is a binary with the changes included:
Sanderling.zip

These are the signatures to use the key methods:

bool WindowPostMessageKeyDown(VirtualKeyCode key, IntPtr lParam = default(IntPtr));
bool WindowPostMessageKeyUp(VirtualKeyCode key, IntPtr lParam = default(IntPtr));

also, can you show me an example of how can I use System.Speech.Synthesis.SpeechSynthesizer class? i would like to be announced of local chat changes ;)

I added a reference to System.Speech.dll to the script compilation to enable using the SpeechSynthesizer from script.

It can be used like this:

using System.Speech.Synthesis;

var synth = new SpeechSynthesizer();

synth.Speak("Sanderling at your service.");

[ALERTua]

everything works perfectly. thank you very much!

now i'm trying to simulate mouse clicks, but it seems the game has some kind of protection against this, so clicks are sent only to the coordinates of cursor on screen, no matter what coordinates are sent. I tried using SendMessage and PostMessage. maybe you will succeed with implementing this. it would be very nice to click all controls without losing focus of current window.
I tried:

const int WM_LBUTTONDOWN = 0x201;
const int WM_LBUTTONUP = 0x202;
const int MK_LBUTTON = 1;
const int MK_RBUTTON = 2;

[DllImport("user32.dll")]
static extern IntPtr PostMessage(IntPtr hWnd, uint Msg, IntPtr wParam, IntPtr lParam);

[DllImport("User32.dll")]
static extern Int32 SendMessage(int hWnd, int Msg, int wParam, int lParam);

int window = FindWindow("triuiScreen", null);

PostMessage((IntPtr)window, WM_KEYDOWN, (IntPtr)WM_LBUTTONDOWN, (IntPtr)(y_coord << 16) | x_coord));

SendMessage(window, WM_KEYDOWN, WM_LBUTTONDOWN, (y_coord << 16) | x_coord );

[ALERTua]

This is weird, but
Sanderling.WindowPostMessageKeyDown(VirtualKeyCode.VK_D);
Sanderling.WindowPostMessageKeyUp(VirtualKeyCode.VK_D);
presses "d" two times.
removing Sanderling.WindowPostMessageKeyUp(VirtualKeyCode.VK_D) causes "d" to be pressed down, not released, but not to spam a letter if chat is focused.
i'm saying that using these two methods to cause a keypress-keyrelease always presses a key twice. can't find the reason yet. this can be bad when trying to activate modules. they will deactivate as soon as they are activated.

[Arcitectus]

I would need to know what assumptions you used in order to understand how you arrived at these conclusions

Sanderling.WindowPostMessageKeyDown(VirtualKeyCode.VK_D);
Sanderling.WindowPostMessageKeyUp(VirtualKeyCode.VK_D);
presses "d" two times.

How did you arrive at this conclusion?

removing Sanderling.WindowPostMessageKeyUp(VirtualKeyCode.VK_D) causes "d" to be pressed down, not released

How did you arrive at this conclusion?

but not to spam a letter if chat is focused.

Why do you expect it to spam?

[ALERTua]

as i understand:
Sanderling.WindowPostMessageKeyDown(VirtualKeyCode.VK_D);
presses down a button D
and
Sanderling.WindowPostMessageKeyUp(VirtualKeyCode.VK_D);
releases it

but when i use these two lines, and my cursor is focused in chat, i see two letters D typed instead of one.

if i try to use only pressing a button without a release (KeyDown without KeyUp), i expect it to become held down and to spam this letter if chat is focused.

[Arcitectus]

as i understand:
Sanderling.WindowPostMessageKeyDown(VirtualKeyCode.VK_D);
presses down a button D
and
Sanderling.WindowPostMessageKeyUp(VirtualKeyCode.VK_D);
releases it

I see. This is not the case. These methods just call the WinAPI function 'PostMessage' and return its return value (The implementation can be seen at

Sanderling/src/Sanderling/Sanderling/Script/ToScriptExtension.cs

Lines 104 to 111 in c487043

	static public bool WindowPostMessage(this IHostToScript host, uint msg, IntPtr wParam, IntPtr lParam = default(IntPtr)) =>
	BotEngine.WinApi.User32.PostMessage(host.WindowHandle, msg, wParam, lParam);
	static public bool WindowPostMessageKeyDown(this IHostToScript host, VirtualKeyCode key, IntPtr lParam = default(IntPtr)) =>
	host.WindowPostMessage(0x100, (IntPtr)key, lParam);
	static public bool WindowPostMessageKeyUp(this IHostToScript host, VirtualKeyCode key, IntPtr lParam = default(IntPtr)) =>
	host.WindowPostMessage(0x101, (IntPtr)key, lParam);

).
The reason the text 'KeyDown' and 'KeyUp' are contained within the method names is that those are also used in the documentation from microsoft which describes the messages which are being posted by these methods (see https://msdn.microsoft.com/en-us/library/windows/desktop/ms646280(v=vs.85).aspx).

For example, a windows application can use the GetAsyncKeyState function to get information about the state of a key. So far, I don't see that the WM_KEYDOWN and WM_KEYUP messages affect the return value of this function as you expect.

[ALERTua]

as for sending a mouse click. i failed multiple times trying to send a click to inactive game window. the closest answer i found was at https://autohotkey.com/board/topic/96814-using-postsendmessage-to-send-clicks-to-game-window/ but even this fails for me. clicks are only sent in current mouse position only if mouse cursor is within game client window. maybe you can spend a little time to investigate this? it would be very nice. tell me if i can somehow help.

[Arcitectus]

clicks are only sent in current mouse position only if mouse cursor is within game client window. maybe you can spend a little time to investigate this? it would be very nice. tell me if i can somehow help.

At the moment it seems the best option is to contain both applications in an VMWare instance or a windows remote desktop session.
So far it seems that investing into research here will not be worth the effort.