locked
Browser control interferes, part 2... RRS feed

  • Question

  •  I've previously posted here regarding a browser object  interfering with text boxes on the form.

    I found that the solution would be to just define, activate and then remove a user defined window.

    Now my problem is how to do this seamlessly. I want this code to run every time the user exits the browser object, ie: when the user clicks the browser object it causes the problem, so when he clicks anything else the code should run.

    I tried to use the lostfocus on the browser object. or even put the browser object into a container and use methods there but nothing helped.

    The only partial solution I have for now is to put a shape in between the browser object and the rest of the form, and use its mouseenter method. But that's problematic because if the user moves the mouse too fast, it won't trigger.

    Any ideas would be appreciated.  Please note that I do not want to put all the rest of the objects in a container...

    Thanks!

    Wednesday, December 18, 2019 2:16 PM

All replies

  • I can reproduce that, but I don't know if it only has to do with the PDF software used. 

    The first level problem is ActiveX controls are their own Windows, have their own HWND, but that in itself usually is no problem, ie when you only navigate to a site you don't get keyboard input stuck inside the PDF viewer embedded within the Browser.

    The overall situation is like Stefan Förner already said in your other thread, using the MS Webbrowser Control means the  SHDOCVW.DLL is used. Displaying a PDF inside the Webbrowser control then uses a plug in or even external EXE depending on what PDF viewer you use, so that even may switch processes.

    Using BindEvent you can bind to windows events happening to your VFP form. You can bind to THISFORM.hwnd in form init and, for example, bind to the windows message WM_MOUSEMOVE  (512). VFPs sample project has examples on what handler method you need to handle these windows message events. 

    You then only get mousemove events for the part of your form that not occupied with the Webbrowser control. On the positive side unlike VFPs form.mousemove that WM_MOUSEMOVE message also triggers the bound eventhandler method when you move over controls, so a mousemove anywhere on the form except the webbrowser is detecatable.

    But before we go into details, this also doesn't help if someone would tabs from the Browser portion into the VFP form portion. also you can't tell when no mousemove message occured you know the focus is on the webbrowser control, it could be anywhere else.

    I guess an easierr solution would be to create an old style eventhandler for the EVENTHANDLER() function as describined at the end of the perhaps most often referred to article about that: https://west-wind.com/presentations/shellapi/shellapi.html. See the paragraph "Handling MSHTML Document Events".

    It's really easier and better to perform what's described there than to give code. What gets pasted into a VFP program editor window when you drag the HtmlDocumentEvents node from the Object Browser has varied and will vary a little, it's best you actually do that. And then you need to follow the rest of the article description on how to make use of that class with a webbrowser control and you need to look into the events you get hands on and which happen, when you change from VFP textbox to Brwoser control and back.

    Bye, Olaf.

    • Edited by OlafDoschke Wednesday, December 25, 2019 3:49 PM
    Sunday, December 22, 2019 2:13 PM
  • Olaf;

    Thank you for the detailed response. I'll put it to good use.

    Wednesday, December 25, 2019 2:29 PM
  • Hi,

    Have you solved this problem now?

    I think the above reply can provide you with a solution, have you tried it?

    If so, hope you can close this thread by marking the reply as answer as this will help others looking for the same or similar issues down the road.

    Best Regards,

    Julie


    MSDN Community Support Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, December 27, 2019 6:32 AM
  • Julie;

    Unfortunately the suggestions by olaf, while helpful, don't really solve my problem. I'm still researching a solution.

    Thursday, January 2, 2020 1:04 AM