keybd_event multiple keys

im using Call keybd_event(System.Windows.Forms.Keys.Tab, 0, 0, 0) function to call keyboard events,

but what if i want to press two keys at once? for instance, alt+tab

thanks

followup: ive been playing around with the process class and i am able to kill and start processes running in the background. but i have not been able to switch the active process similar to alt+tab

You can send an Alt + Tab like this.

VB Code:

Const VK_MENU = &H12
        Const KEYEVENTF_KEYUP As Long = &H2
        keybd_event(VK_MENU, 0, 0, 0) 'Alt down
        keybd_event(System.Windows.Forms.Keys.Tab, 0, 0, 0) 'Tab down
        keybd_event(System.Windows.Forms.Keys.Tab, 0, KEYEVENTF_KEYUP, 0) 'Tab up
        keybd_event(VK_MENU, 0, KEYEVENTF_KEYUP, 0) 'Alt up

You can send more tab presses to change the tab selection for which program to set as the active app.

great thanks rob dog. i will try this when i get back to the office monday. one other quesiton. is there a way, instead of using alt+tab to switch applications. i am able to get a list of processes in the background. can i have vb tell explorer to make a certain process active, and then perform certain keystrokes using the code you just gave?

Yes there is. You need to use the Process object to get a list of runnig processes on your system and then you can terminate or
activate the one you want.

yup i was able to kill processes using the kill function, but i wasnt able to find the activate function. do you know of it off hand. also, how would one find a list of all the functions? on the msdn website?

There is a function called AppActivate that will do the job. It is in the Microsoft.VisualBasic namespace, however, so will not be considered pure .NET. Also, it won't restore the app window if it is minimised.

You can also simulate the ALT+TAB key press with SendKeys.Send("%{TAB}").

Isnt the SendKeys method just a wrapper around the old vb6 SendKeys? I usually try to avoid it whenever I can since its unreliable.

Quote:

---

Originally Posted by RobDog888

Isnt the SendKeys method just a wrapper around the old vb6 SendKeys? I usually try to avoid it whenever I can since its unreliable.

---

I really don't know what goes on under the hood of SendKeys, but the class is a memebr of the System.Windows.Forms namespace. If it was a wrapper for an old VB6 method then I would have expected it to be a member of Microsoft.VisualBasic. Remember that all members of any .NET Framework namespace (one that starts with System) are available to any .NET language, not just Visual Basic.

Either way, wouldnt the logic of SendKeys still be the same if it was in the .NET FW or MS VB Namespance? If it is then its still unreliable.

Who's to say that the implementation of System.Windows.Forms.SendKeys.Send doesn't actually use the same method that you are proposing? I don't know that it does, but I also don't know that it doesn't. I've not heard anyone complain about it being unreliable, but that also doesn't mean that it's not. I just think that we should give a "pure .NET" method, that appears to do the job required, the benefit of the doubt before resorting to APIs.

Agreed ;) but I have herd that you can write your APIs as managed code instead of unmanaged?

Quote:

---

Originally Posted by RobDog888

Agreed ;) but I have herd that you can write your APIs as managed code instead of unmanaged?

---

I could be wrong, but I would think that that would just mean wrapping your API calls in a class or module in a .NET assemby. You're still calling functions in Windows system libraries however you go about it.

By the way, nice badger! Minimally psychedelic.

Yes, but if the APIs are managed code then couldnt that be considered .NET code. :D

Thanks, I gave a few members seizures so I had to change it. :lol:

I guess it depends what you consider to be .NET code. I could wrap calls to functions in Microsoft.VisualBasic in a .NET assembly but I know some members of this forum would be horrified to use it. I think that to be considered "pure .NET" code would have to use only in-built language features and objects and methods from the .NET Framework. Anything outside of that, I would think, has to be considered non-.NET. Not that that's a crime, and who knows how the objects and methods in the Framework are implemented anyway?

As a point of interest, note that registry access is achieved through the Microsoft.Win32 namespace. I know that Microsoft discourages using the registry in .NET apps, certainly to store data at least. Would you consider registry access to be non-.NET?