detecting keystrokes even when minimized/hidden =(

I'm making a program that raises/lowers sound volume, but I can't manage to make it detect when I hold down the Ctrl+Alt+Up Arrow Key

I need it to know when I press Cntrl+Alt+ArrowKeys even when the form is hidden or minimized as a system tray icon. Any ideas? I'm noy very good with API, but I guess that's where the solution's at.

Any help will be greatly appreciated!
(And please don't refer me to the keylogger example also in this forum, I'm looking for another possibility)

You need a system-wide hook. Search msdn.microsoft.com for "system hook" and see what turns up.

Some people use GetAsyncKeyState(), but personally, I don't like it too much.

Regarding the keyboard hook, you'll need to use C++ or Delphi to create it, because VB cannot create a standard DLL. You will, however, have to load the library and install the hook in VB. The only think that goes in the DLL is the hook procedure.

Megatron: can't you use AddressOf to do the hook callback in VB? I've read about doing that sort of thing...

Quote:

---

Originally posted by mlewis
Megatron: can't you use AddressOf to do the hook callback in VB? I've read about doing that sort of thing...

---

yes, you can do that.

the easiest thing to do would be to use the getkeystate or getasynckeystate api's...

It works, yes!

Quote:

---

Originally posted by mlewis
Megatron: can't you use AddressOf to do the hook callback in VB? I've read about doing that sort of thing...

---

No. AddressOf can only retrieve the address of a function within the current module. And even if it could get functions from a DLL, it still wont work, because in order for the DLL to be loaded in the address space of all processes, the procedure needs to be in a DLL.

To retrieve the address of a procedure, use GetProcAddress

Sure, i meant that. :rolleyes:
I wanted to say, that it is possible to use a system wide keyboard hook with some DLL.
They are precompiled on the web.

Urhm, Megatron, a callback is in the current module, by definition...:confused:

Ok, it is possible. For testing purposes, lets move our form when the focus is on some other window.

Module Code

VB Code:

Private Declare Function GetAsyncKeyState Lib "user32" (ByVal vKey As Long) As Integer
Public Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (Destination As Any, Source As Any, ByVal Length As Long)
Public Declare Function GetKeyState Lib "user32" (ByVal nVirtKey As Long) As Integer
Public Declare Function SetWindowsHookEx Lib "user32" Alias "SetWindowsHookExA" (ByVal idHook As Long, ByVal lpfn As Long, ByVal hmod As Long, ByVal dwThreadId As Long) As Long
Public Declare Function CallNextHookEx Lib "user32" (ByVal hHook As Long, ByVal nCode As Long, ByVal wParam As Long, lParam As Any) As Long
Public Declare Function UnhookWindowsHookEx Lib "user32" (ByVal hHook As Long) As Long
Public Const HC_ACTION = 0
Public Const WM_KEYDOWN = &H100
Public Const WM_KEYUP = &H101
Public Const WM_SYSKEYDOWN = &H104
Public Const WM_SYSKEYUP = &H105
Public Const VK_CONTROL = &H11
Private Const VK_RSHIFT = &HA1
Public Const VK_MENU = &H12
Private Const VK_LEFT = &H25
Private Const VK_RIGHT = &H27
Public Const VK_UP = &H26
Public Const VK_DOWN = &H28
Public Const WH_KEYBOARD_LL = 13
Public Const LLKHF_ALTDOWN = &H20
 
 
Public Function KeyboardProc(ByVal nCode As Long, ByVal wParam As Long, ByVal lParam As Long) As Long
    Dim intFFN As Integer
    
    If (nCode = HC_ACTION) Then
        If wParam = WM_KEYDOWN Or wParam = WM_SYSKEYDOWN Then
            If (GetKeyState(VK_CONTROL) And &H8000) <> 0 Then
                If (GetKeyState(VK_MENU) And &H8000) <> 0 Then
                    If (GetKeyState(VK_UP) And &H8000) <> 0 Then
                        With Form1
                            .Move .Left, .Top - 100
                        End With
                    ElseIf (GetKeyState(VK_DOWN) And &H8000) <> 0 Then
                        With Form1
                            .Move .Left, .Top + 100
                        End With
                    ElseIf (GetKeyState(VK_LEFT) And &H8000) <> 0 Then
                        With Form1
                            .Move .Left - 100, .Top
                        End With
                    ElseIf (GetKeyState(VK_RIGHT) And &H8000) <> 0 Then
                        With Form1
                            .Move .Left + 100, .Top
                        End With
                    End If
                End If
            End If
        End If
    End If
    KeyboardProc = CallNextHookEx(0, nCode, wParam, ByVal lParam)
End Function

Form Code

VB Code:

Dim m_lngKeyboad As Long
 
Private Sub Form_Unload(Cancel As Integer)
    If m_lngKeyboad <> 0 Then UnhookWindowsHookEx m_lngKeyboad
End Sub
 
Private Sub Form_Load()
    m_lngKeyboad = SetWindowsHookEx(WH_KEYBOARD_LL, AddressOf KeyboardProc, App.hInstance, 0)
End Sub

By pressing CTRL+ALT+UP, CTRL+ALT+DOWN, CTRL+ALT+LEFT, CTRL+ALT+RIGHT - the form will be moved accordingly even if you have the focus on some other window.

That didn't work for me :rolleyes:

Quote:

---

Originally posted by mlewis
Megatron: can't you use AddressOf to do the hook callback in VB? I've read about doing that sort of thing...

---

Yes, you can do it in VB, but it will not respong globally (as shown by Serge).

Quote:

---

Originally posted by mlewis
Urhm, Megatron, a callback is in the current module, by definition...:confused:

---

Windows will load the procedure in the address space of all running threads.

responds globally for me; I can be in a totally different app and press CTL+ALT+Left/right/etc and it moves just great. You do have to hold the key down for about a second for it to activate, but thats no big deal.

Megatron, what are you talking about? AddressOf gets the address of a function (or sub if you want to be picky) Windows calls into that memory space, it doesn't load a separate copy of the function for each process! If it loaded a new copy of your code in every process, it would either have to load the whole EXE/DLL (otherwise global variables etc. would be lost) or it would crash every time you tried it.

So now you're arguing with one of the best people on the forums :rolleyes:

http://msdn.microsoft.com/library/de...hooks_7vaw.asp

Quote:

---

[in] Handle to the DLL containing the hook procedure pointed to by the lpfn parameter. The hMod parameter must be set to NULL if the dwThreadId parameter specifies a thread created by the current process and if the hook procedure is within the code associated with the current process.

---

I am sorry but I still do not understand that quote to mean that the procedure is loaded into all other process's memory space.

If I am incorrect please point out where and list some clear examples. I do not mind being wrong.

It means that if you want to install a system wide hook, that you need a DLL containing the hook procedure to be loaded into the memory i think

Megatron will have a good answer i think though ;)

Quote:

---

Originally posted by da_silvy
It means that if you want to install a system wide hook, that you need a DLL containing the hook procedure to be loaded into the memory i think

Megatron will have a good answer i think though ;)

---

Hmmm...thats what I thought; musta misunderstood something above (do that a lot nowdays, blegh)

hehhehe

I have to read some posts several times to pick up what people are actually trying to ask now.

It's like they're asking questions in some secret langauge :eek:

Well there's a lot of people from non-english speaking countries (or at least, countries that don't speak english as main language) so that's probably got a lot to do with it.

Then of course there's those annoying people who always talk in l4m3r...0h w311 wh0 c4r3z? :rolleyes:

Then there's ali g

Who is hard to understand - whether he is complimenting you or paying you out :eek:

Quote:

---

Originally posted by mlewis
Megatron, what are you talking about? AddressOf gets the address of a function (or sub if you want to be picky)...

---

I'm not talking about AddressOf here. I'm talking about global hooks with SetWindowsHookEx.

Right out of MSDN docs on SetWindowsHookEx:

Quote:

---

lpfn
Pointer to the hook procedure. If the dwThreadId parameter is zero or specifies the identifier of a thread created by a different process, the lpfn parameter must point to a hook procedure in a dynamic-link library (DLL). Otherwise, lpfn can point to a hook procedure in the code associated with the current process.

---

I read the whole artice through, and it mentions nothing about loading your code into all process's memory space (as you said above)

meh

There's some reason, a guru will most likely tell you...

I'd like to step back to the original poster of this thread. A while ago, enriquein asked:

Quote:

---

Where did ya guys learn the API in the fisrt place?

---

Most of us learned from trial and error, experience, and playing around with making API calls that we saw in magazines or books. This is a great site to get a head start. Another VERY good site is http://www.allapi.net/ - This site also offers a free API Viewer which you can down load. Unlike the API viewer that comes with VB, this one actually has examples of how to use the APIs, and has some explanation on what they do and are used for. Don't be discouraged if you have an API blow up in your face. I would venture to say that that has happened to everyone at some point or other.

yes, all programmers will make huge mistakes that blow up in their face, but you debug, find the mistake, and end up w/ a half decent program (sometimes)... im still learnin the api though, i think im gunna start making graphs based upon how many times a day i have to restart because i made a mistake w/ the api...

There are problems with that though skitchen.

When you subclass you can't debug so it really is a pain in the a$$.

That means you have to be careful, or not mind restarting vb every time there is a problem :rolleyes:

well, you can end the subclassing through your programming, you just have to call the event to close the hook (can't remember it off hand)

If your code has a fatal error it will never call the close hook code, is the point I think.

Try it:

'set subclass hook here
...
Dim A
A= 1/0


Now watch the chain of events : subclass hook never removed, PC goes down...

Quote:

---

Originally posted by mlewis
Right out of MSDN docs on SetWindowsHookEx:

I read the whole artice through, and it mentions nothing about loading your code into all process's memory space (as you said above)

---

In order for a process to have access to the functions in the DLL, it must load the DLL first (how can you retrieve functions from nothing ?). So essentially, each process will load the library, and keep the library loaded even after you uninstall the hook, hence keeping the OS in it's state of slow-processing. This is why global hooks are a big no-no.

Quote:

---

Originally posted by mlewis
If your code has a fatal error it will never call the close hook code, is the point I think.

Try it:

'set subclass hook here
...
Dim A
A= 1/0


Now watch the chain of events : subclass hook never removed, PC goes down...

---

that's only if it's compiled i think

If you do it in vb dev, it just closes the vb ide...

Yep, did it to me. VB Closed wiithoot even giving an error.

But some dude sent me a URL of a web page that has a ActiveX COntrol that detects the keys, it's pretty damn good!

Cant remember the name or website thou!

And thanx for the advice on API, know about any good books? I tried the allapi.net program and its pretty good, but I'd like some more reference.

Quote:

---

Originally posted by Megatron

In order for a process to have access to the functions in the DLL, it must load the DLL first (how can you retrieve functions from nothing ?). So essentially, each process will load the library, and keep the library loaded even after you uninstall the hook, hence keeping the OS in it's state of slow-processing. This is why global hooks are a big no-no.

---

The way DLLs work is they load into 1 memory space (except certain types, or DLLs which expose in-process COM objects) then all programs share that RAM space. That was the idea behind creating DLLs in the first place.

DLLs only load into each process if they expose Inprocess ActiveX servers.

da_silvy

you can debug when subclassed mate, get the DLL from MS that enables you to do this, then use some conditional compilation and you're away - I use Bryan Staffords classes they work great for me, and you can do all sorts of cool stuff with them, which includes debugging.....

www.mvps.org/vbvision

and

http://www.mvps.org/vbvision/dbugproc_dll.htm

thanks for that insight mate, i will check it out ;)