# Visual Basic > Slow Chat with the Microsoft Visual Basic team >  Will SendKeys.Send ever be replaced so that it's more reliable?

## TTn

Hello guys and gals!

It's pretty common that we get people in here asking about sendkeys, and usually most gurus and moderators will suggest that it's not really the best idea, because it's really not. :Smilie:  

One of the main problems with the concept, is ofcourse stray keyboard focus.
So it would be nice to see a sendkeys.Send, that has a managed way to activate and send input to a particular window identified by the developer,
and also not have it interupted by the user, as sendkeys does.  MSDN suggests using FindWindow and Setforegroundwindow, which is okay, but even that does'nt completely ensure focus.  It would also be nice to have a method that waits for a new window, that has been invoked by the keyboard strokes, ie {Enter}.  This way the automation can then continue on, in a linear manner.

I myself wrote such an input class in VB.NET, that can also simulate mouse events.
InputToWin
I've found it very helpful, and stable in automating tasks, that I can already do as a user.
Feel free to use it as a sketch, or idea template.

PS  I need a job! :Smilie:

----------


## Paul M

What do you mean "doesn't completely ensure focus"?

If you use SetFocus() then it should ensure complete focus.

----------


## RobDog888

All it takes to throw your sendkeys code out of sync even with all the functions and methods you can think of is still flakey as the user can be clicking or keying data which can easily change the input focus while your code runs.  :Wink:

----------


## Paul M

But we can't help that, no matter what solution replaces SendKeys the input focus could change at any moment. Or is there a way? I wouldn't have the faintest idea.

----------


## RobDog888

The most solid way to transfering data to another external window is to use APIs like FindWindow, FindWindowEx and SendMessage and PostMessage APIs. These directly interface with the windows message stream of the identified window so it doesnt matter whats going on in the windows session.

@TTn, So basically you are asking if the VB Team will ever produce API-like functionality and stability with the simple SendKeys method?

----------


## Paul M

Yea thats how i use to do it in VB6  :Smilie: 

Couldn't the keybd_event() API be a better way?

----------


## Paul M

Never mind, just read the documentation on keybd_event looks like it can simulate keystrokes but wouldn't be of much help, please enlighten me if i am wrong.

----------


## TTn

Setforegroundwindow does'nt work occasionally when the recieving window is flashing in the task bar.
I actually lost the link to msdn, which mentions something about it, and suggested pressing the menu key first(paraphrasing), to reset focus availability.
I had already found that by using the Ctrl-Alt combo instead, avoids having the current app in focus,
from underlining it's menu shortcuts for no reason, as the menu key would alone.  It's just cleaner that way.  
Oh and just because you've set the foreground window, doesn't mean it is forced to stay there for long if called elsewhere.

I actually was able to help someone in these forums in desperate need of solving the problem because of a flashing window, that didn't accept focus even though it should have.  Sure i guess using SendKeys.Send("%") first would work, but this should built within the method.

There are other API that have the word Foreground in them that apply like AllowSetForegroundWindow, and apiLockSetForegroundWindow.

I'm pretty sure that *SetFocus* only works on the current thread, so you'd have to try AttatchInputThread to MAYBE get that to work outside your own app.  I do that with GetFocus, which can get the handle of any child, regardless of thread input.

----------


## TTn

> The most solid way to transfering data to another external window is to use APIs like FindWindow, FindWindowEx and SendMessage and PostMessage APIs


Correct, you should always try this route first, and i included methods within InputToWin that wrap that up.
However you'll still run into things that cannot be done with sendMessage and PostMessage.  Hence the need, for using keyboard event api, which also is more friendly to beginers, that dont know about handles yet.




> TTn, So basically you are asking if the VB Team will ever produce API-like functionality and stability with the simple SendKeys method?


Yes, basically whatever it takes.

----------

