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. Hook Messages: MFC HWND vs OLE control

Hook Messages: MFC HWND vs OLE control

Scheduled Pinned Locked Moved C / C++ / MFC
questionc++javascripthtmlvisual-studio
6 Posts 3 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.
  • I Offline
    I Offline
    internal
    wrote on last edited by
    #1

    All questions come from the javascript call window.blur() method I'm fighting now. I'm hosting chtmlview in a mdi app. When a html page with the blur() call my app brings to back and deactivated. I only want to user controls de/activate actions but the page. 1. I install a thread message hook and catch WM_WINDOWPOSCHANGING/WM_CAPTURECHANGED/WM_KILLFOCUS of hwnd Internet Explorer_Server, that's all I could find with spy++. But without call CallNextHookEx spy++ still tell that hwnd named Internet Explorer_Server received these messages! Is ole control live in a different message pump world? 2. So how can I catch the blur call? Go to upward with WM_ACTIVATEAPP or downward with eventsink HTMLWindowEvents::onblur:confused: Sing when we're programming.

    I 1 Reply Last reply
    0
    • I internal

      All questions come from the javascript call window.blur() method I'm fighting now. I'm hosting chtmlview in a mdi app. When a html page with the blur() call my app brings to back and deactivated. I only want to user controls de/activate actions but the page. 1. I install a thread message hook and catch WM_WINDOWPOSCHANGING/WM_CAPTURECHANGED/WM_KILLFOCUS of hwnd Internet Explorer_Server, that's all I could find with spy++. But without call CallNextHookEx spy++ still tell that hwnd named Internet Explorer_Server received these messages! Is ole control live in a different message pump world? 2. So how can I catch the blur call? Go to upward with WM_ACTIVATEAPP or downward with eventsink HTMLWindowEvents::onblur:confused: Sing when we're programming.

      I Offline
      I Offline
      igor1960
      wrote on last edited by
      #2

      Instead of installing a hook, why not just dynamically subclass "Internet Explorer_Server" window? Did you try that?... As to hook and why it doesn't stop the message: Check, What hook are you using GETMESSAGE or CALLWND??? "...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..." Me

      I J 2 Replies Last reply
      0
      • I igor1960

        Instead of installing a hook, why not just dynamically subclass "Internet Explorer_Server" window? Did you try that?... As to hook and why it doesn't stop the message: Check, What hook are you using GETMESSAGE or CALLWND??? "...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..." Me

        I Offline
        I Offline
        internal
        wrote on last edited by
        #3

        Igor anywhere?:-D when javascript:window.blur()is called the WM_WINDOWPOSCHANGING message is sent directly to the CMainFrame, that's the differece from moveto and resize. So I suspect the ie control or ole container done different ways. All knowledge is gathered from spy++ and I want to know why in theory. Who controls the message goes up way in OLE control? OLE container or the browser itself? Sing when we're programming.

        I 1 Reply Last reply
        0
        • I internal

          Igor anywhere?:-D when javascript:window.blur()is called the WM_WINDOWPOSCHANGING message is sent directly to the CMainFrame, that's the differece from moveto and resize. So I suspect the ie control or ole container done different ways. All knowledge is gathered from spy++ and I want to know why in theory. Who controls the message goes up way in OLE control? OLE container or the browser itself? Sing when we're programming.

          I Offline
          I Offline
          igor1960
          wrote on last edited by
          #4

          According to Microsofts IHTMLWindow2::blur Method documentation http://msdn.microsoft.com/library/default.asp?url=/workshop/browser/mshtml/reference/ifaces/window2/blur.asp blur causes losing focus by web browser. Instead of chasing messages with spy, maybe better approach is to write an even handler for html window::onblur event and SetFocus back to web browser and possibly activate your app... As to the ways ActiveX control can negotiate with container -- they are not necessary OLE messages. I'm absolutely sure that MSFTs WebBrowser control talking to your frame window through Win32 messages too in addition to Ole ClientSite mechanism... At least that what MSFT allowes to do for themselves, while publishing rules for others... Regards... "...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..." Me

          I 1 Reply Last reply
          0
          • I igor1960

            According to Microsofts IHTMLWindow2::blur Method documentation http://msdn.microsoft.com/library/default.asp?url=/workshop/browser/mshtml/reference/ifaces/window2/blur.asp blur causes losing focus by web browser. Instead of chasing messages with spy, maybe better approach is to write an even handler for html window::onblur event and SetFocus back to web browser and possibly activate your app... As to the ways ActiveX control can negotiate with container -- they are not necessary OLE messages. I'm absolutely sure that MSFTs WebBrowser control talking to your frame window through Win32 messages too in addition to Ole ClientSite mechanism... At least that what MSFT allowes to do for themselves, while publishing rules for others... Regards... "...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..." Me

            I Offline
            I Offline
            internal
            wrote on last edited by
            #5

            I've dug into wrong way:(( As you said the right logic is even if my main window takes some actions not expected it must receive some messages in win32 way! So spy++ always rules:cool: I will remember that till the water runs dry;P Interface event sink is another way. But no parameter to cancel it and too much code to write. Only mfc involved in that's simple and clean. Sing when we're programming.

            1 Reply Last reply
            0
            • I igor1960

              Instead of installing a hook, why not just dynamically subclass "Internet Explorer_Server" window? Did you try that?... As to hook and why it doesn't stop the message: Check, What hook are you using GETMESSAGE or CALLWND??? "...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..." Me

              J Offline
              J Offline
              Jeffster
              wrote on last edited by
              #6

              Are you sure you know what you are talking about?

              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