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. SetWindowsHookEx gives desired result only once?

SetWindowsHookEx gives desired result only once?

Scheduled Pinned Locked Moved C / C++ / MFC
c++adobequestion
6 Posts 4 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.
  • R Offline
    R Offline
    ROWALI
    wrote on last edited by
    #1

    In my dialog based MFC application, I initiate windows hook as follows HHOOK TheHook; LRESULT CALLBACK ShellProc( int nCode, WPARAM wParam, LPARAM lParam ); BOOL CTmphookDlg::OnInitDialog() { .. .. HINSTANCE ppI = AfxGetInstanceHandle(); TheHook=SetWindowsHookEx(WH_SHELL, ShellProc, ppI,0); .. .. } LRESULT CALLBACK ShellProc( int nCode, WPARAM wParam, LPARAM lParam ) { if(nCode==HSHELL_WINDOWCREATED) { HWND hWnd = (HWND)(wParam); char szClassName[256]; GetClassName(hWnd, szClassName, sizeof(szClassName)); AfxMessageBox(szClassName); } return CallNextHookEx(TheHook, nCode, wParam, lParam); } What I want is when any window (other applications) is created on the operating system.. it should flash a message telling its class name. But this code only shows its class name initially when the dialog is being created. I tried to open notepad or other windows of other applications, it didnt flash any message. Why is that so.? What to do to get this? Row

    S 1 Reply Last reply
    0
    • R ROWALI

      In my dialog based MFC application, I initiate windows hook as follows HHOOK TheHook; LRESULT CALLBACK ShellProc( int nCode, WPARAM wParam, LPARAM lParam ); BOOL CTmphookDlg::OnInitDialog() { .. .. HINSTANCE ppI = AfxGetInstanceHandle(); TheHook=SetWindowsHookEx(WH_SHELL, ShellProc, ppI,0); .. .. } LRESULT CALLBACK ShellProc( int nCode, WPARAM wParam, LPARAM lParam ) { if(nCode==HSHELL_WINDOWCREATED) { HWND hWnd = (HWND)(wParam); char szClassName[256]; GetClassName(hWnd, szClassName, sizeof(szClassName)); AfxMessageBox(szClassName); } return CallNextHookEx(TheHook, nCode, wParam, lParam); } What I want is when any window (other applications) is created on the operating system.. it should flash a message telling its class name. But this code only shows its class name initially when the dialog is being created. I tried to open notepad or other windows of other applications, it didnt flash any message. Why is that so.? What to do to get this? Row

      S Offline
      S Offline
      Stephen Hewitt
      wrote on last edited by
      #2

      You're calling SetWindowsHookEx with the dwThreadId set to zero and the hMod set the the .EXE module handle. If you look at the documentation you'll see the following:

      dwThreadId
      [in] Specifies the identifier of the thread with which the hook procedure is to be associated.
      If this parameter is zero, the hook procedure is associated with all existing threads running
      in the same desktop as the calling thread.

      All global hook functions must be in libraries.

      In short you're you're using a global hook and global hook procudures must be in a DLL (that's how it gets into the address space of another process; the other processes loads it). You're hook procudure is in the MFC .EXE. Steve

      F 1 Reply Last reply
      0
      • S Stephen Hewitt

        You're calling SetWindowsHookEx with the dwThreadId set to zero and the hMod set the the .EXE module handle. If you look at the documentation you'll see the following:

        dwThreadId
        [in] Specifies the identifier of the thread with which the hook procedure is to be associated.
        If this parameter is zero, the hook procedure is associated with all existing threads running
        in the same desktop as the calling thread.

        All global hook functions must be in libraries.

        In short you're you're using a global hook and global hook procudures must be in a DLL (that's how it gets into the address space of another process; the other processes loads it). You're hook procudure is in the MFC .EXE. Steve

        F Offline
        F Offline
        FarPointer
        wrote on last edited by
        #3

        http://neworder.box.sk/newsread.php?newsid=10952[^] Please check this out . Regards, FarPointer Blog:http://farpointer.blogspot.com/

        P S 2 Replies Last reply
        0
        • F FarPointer

          http://neworder.box.sk/newsread.php?newsid=10952[^] Please check this out . Regards, FarPointer Blog:http://farpointer.blogspot.com/

          P Offline
          P Offline
          peterchen
          wrote on last edited by
          #4

          ...which basically turns the EXE into a DLL :rolleyes:


          Some of us walk the memory lane, others plummet into a rabbit hole
          Tree in C# || Fold With Us! || sighist

          1 Reply Last reply
          0
          • F FarPointer

            http://neworder.box.sk/newsread.php?newsid=10952[^] Please check this out . Regards, FarPointer Blog:http://farpointer.blogspot.com/

            S Offline
            S Offline
            Stephen Hewitt
            wrote on last edited by
            #5

            WH_KEYBOARD_LL and WH_MOUSE_LL are special cases. The following is a quote from MSDN:  "However, the WH_KEYBOARD_LL hook is not injected into another process. Instead, the context switches back to the process that installed the hook and it is called in its original context. Then the context switches back to the application that generated the event." This is why the example he gave works; it has nothing to do with his Microsoft conspiracy theories. My advice is to follow the rules and ignore that article. Steve

            F 1 Reply Last reply
            0
            • S Stephen Hewitt

              WH_KEYBOARD_LL and WH_MOUSE_LL are special cases. The following is a quote from MSDN:  "However, the WH_KEYBOARD_LL hook is not injected into another process. Instead, the context switches back to the process that installed the hook and it is called in its original context. Then the context switches back to the application that generated the event." This is why the example he gave works; it has nothing to do with his Microsoft conspiracy theories. My advice is to follow the rules and ignore that article. Steve

              F Offline
              F Offline
              FarPointer
              wrote on last edited by
              #6

              You are right steve. Regards, FarPointer Blog:http://farpointer.blogspot.com/

              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