We are seeking to develop a long-term association for external programming and as proof of ability we require help fixing a mouse-pointer bug that prevents proper behaviour of embedded Internet Explorer from within a 3D application?
Our application is compiled from C++ source and is not using MFC or .NET. Its visual output is all via a Direct3D rendered window and MUST REMAIN SO for the purposes of this project.
We are using OLE/COM to embed a CLSID_WebBrowser control in a (C++, no MFC) 3D application. The web browser control window remains hidden, NEVER draws directly to the display and NEVER receives direct UI input (mouse move etc) from Windows. Instead its output is captured on to a texture using OleDraw() and input is supplied via PostMessage() from the main application.
The Web browser control display output is working correctly although we have been unable to persuade it to use the IOleInPlaceSiteWindowless interface the application provides, which would be a lot more efficient.
The application receives mouse move / click etc messages from Windows in the normal way and after determining which UI object the user has clicked should receive the message and scaling of position co-ordinates as needed, this message is passed on to the hidden web browser control window via PostMessage().
Problem 1: Mouse Position being 'lost'
When the mouse is first positioned over a link in a web page and then held over that position, the link will be underlined correctly for a short period of time but then the underline disappears even though the mouse has not moved (it ought to remain there for as long as the mouse is over it, so our guess is that something is interrupting the messages – see ‘what we’ve already tried’, below).
Problem 2: Flash elements respond only intermittently
On clickable Flash elements (eg. buttons and other controls), their response to being clicked is intermittent - sometimes it will work, sometimes not, even on the same control with the mouse in the same position (which again suggests that, as with Problem 1, something may be interrupting these messages – see below).
We have tried lots of different ways of correcting this behaviour.
a) We have verified that the co-ordinates being passed are correct.
b) We have tried delivering the messages to different child windows of the main web control container window.
c) We have used SendMessage() instead of PostMessage().
d) We have tried sending new mousemove messages even when the mouse is stationary (simply repeating the ‘send’ of the mouse’s current coordinates). However, when we do this, the link just flashes on and off at regular intervals.
e) We have also tried sending mouse hover messages when the mouse is stationary.
We are now wondering if the web control is requesting the mouse position directly from Windows, in which case the co-ordinates it receives will be of no use and won't match up to the element the mouse is really hovering over.
We are not aware of a method of discovering if this is the case, or intercepting the request if this is what's happening.
We are not prepared to release source code and therefore require a quote based on detailed advise regarding a workable solution. This in turn will demonstrate your ability in respect of the development of a longer-term relationship.