Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. Keystroke log in a service

Keystroke log in a service

Scheduled Pinned Locked Moved C / C++ / MFC
question
3 Posts 2 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • D Offline
    D Offline
    De Nardis Andrea
    wrote on last edited by
    #1

    Hi all, is it possible to intercept keystrokes in a service? Every Service run in a different desktop from the one a user logs, so basically I think this service should grab any keystrokes in any desktop. Do you have any experience on that? Thanx alot n' Merry Xmas. :-D

    R 1 Reply Last reply
    0
    • D De Nardis Andrea

      Hi all, is it possible to intercept keystrokes in a service? Every Service run in a different desktop from the one a user logs, so basically I think this service should grab any keystrokes in any desktop. Do you have any experience on that? Thanx alot n' Merry Xmas. :-D

      R Offline
      R Offline
      Robert Kuster
      wrote on last edited by
      #2

      > ..so basically I think this service should grab any keystrokes in any desktop Not at all. :) To grab keystrokes you have to call the SetWindowsHookEx API. Problem: SetWindowsHookEx resides in user32.dll and user32 functions are generally bound to a specific desktop. Because most services don't run under the logged-on user account you won't be able to grab the keystrokes of the loged-on user either (nor the keystrokes of any other desktop, like WinLogon for example) - at least not directly. Fortunately there are two exceptions to the above rule: 1. Services running under the local System account can be made interactive. In other words, they can interact with the user and thus grab its keystrokes too. But this way you will only grab the keystrokes of the loged-on users desktop -> it's the same as if you would make an ordinary win32 exe right away. 2. You can "connect" a (service) thread to a desktop via SetThreadDesktop. Knowing this, you could try on of the following: a) Spawn a new thread for each desktop that is present on the system; then call SetThreadDesktop and SetWindowsHookEx from within each thread. b) Since there is only one interactive desktop (=desktop, that receives the user input) at any time, simply call SetThreadDesktop and SetWindowsHookEx always when the active desktop gets switched. Note: This were just presumptions from the top of my head -> for the exact behavior/terminology and implementation check the MSDN documentation. RK

      D 1 Reply Last reply
      0
      • R Robert Kuster

        > ..so basically I think this service should grab any keystrokes in any desktop Not at all. :) To grab keystrokes you have to call the SetWindowsHookEx API. Problem: SetWindowsHookEx resides in user32.dll and user32 functions are generally bound to a specific desktop. Because most services don't run under the logged-on user account you won't be able to grab the keystrokes of the loged-on user either (nor the keystrokes of any other desktop, like WinLogon for example) - at least not directly. Fortunately there are two exceptions to the above rule: 1. Services running under the local System account can be made interactive. In other words, they can interact with the user and thus grab its keystrokes too. But this way you will only grab the keystrokes of the loged-on users desktop -> it's the same as if you would make an ordinary win32 exe right away. 2. You can "connect" a (service) thread to a desktop via SetThreadDesktop. Knowing this, you could try on of the following: a) Spawn a new thread for each desktop that is present on the system; then call SetThreadDesktop and SetWindowsHookEx from within each thread. b) Since there is only one interactive desktop (=desktop, that receives the user input) at any time, simply call SetThreadDesktop and SetWindowsHookEx always when the active desktop gets switched. Note: This were just presumptions from the top of my head -> for the exact behavior/terminology and implementation check the MSDN documentation. RK

        D Offline
        D Offline
        De Nardis Andrea
        wrote on last edited by
        #3

        Thanx a lot. I will check for something. Merry xmas

        1 Reply Last reply
        0
        Reply
        • Reply as topic
        Log in to reply
        • Oldest to Newest
        • Newest to Oldest
        • Most Votes


        • Login

        • Don't have an account? Register

        • Login or register to search.
        • First post
          Last post
        0
        • Categories
        • Recent
        • Tags
        • Popular
        • World
        • Users
        • Groups