(note: reason for posting here; browser helper object is written in
C++; C++ developers tend to know the intricacies of message handling;
this looks like a Windows messaging issue)
Microsoft very kindly make available a DLL (the browser helper DLL)
which allows you to trap and disable the context menu (right mouse
click) and various 'built-in' browser accelerators (such as ctrl+P
which brings up the print dialogue, and F5, which will refresh the
current page) when using the browser.
This is great, and I am duly grateful. However, using the helper DLL
does have a strange side-effect which is annoying our users, and if
anyone has an explanation, I'd be grateful.
What happens is this. If you have any contenteditable fields in your
page (and we have a *lot* of them
e.g
<span contenteditable >some editable stuff</span>
and you host this page inside Visual Basic using the standard browser
control
then without the browser helper DLL attached to the page you can press
the left mouse button and 'sweep' over the text to highlight it. This
is of course a standard piece of Windows behaviour.
Now attach the helper DLL. Now, you can no longer sweep across and
highlight text. Instead, nothing happens.
However, the keyboard still allows this e.g you can press HOME and
CTRL+END to highlight text.
I have tried running up Spy++ to see if somehow there's something
weird going on with message handling but can't pin it down. The DLL
source code doesn't seem to be screwing around with messages it didn't
ought to be handling.
Can anyone suggest a way of pinning down this rather strange problem?.
I strongly suspect it is tied in with message handling/ accelerators
or something weird in this area. I can't see obvious message eating
but how Windows internally handles this I am not sure. I would assume
that the destination hWnd sees a WM_LBUTTONDOWN and then captures the
mouse and monitor WM_MOUSEMOVE messages to handle highlighting, but as
this behaviour is intrinsic to the edit control, I don't see it
documented anywhere. (of course, I assume that contenteditable text is
implemented via an edit control - I have no idea how MS are doing it
inside the browser).
C++; C++ developers tend to know the intricacies of message handling;
this looks like a Windows messaging issue)
Microsoft very kindly make available a DLL (the browser helper DLL)
which allows you to trap and disable the context menu (right mouse
click) and various 'built-in' browser accelerators (such as ctrl+P
which brings up the print dialogue, and F5, which will refresh the
current page) when using the browser.
This is great, and I am duly grateful. However, using the helper DLL
does have a strange side-effect which is annoying our users, and if
anyone has an explanation, I'd be grateful.
What happens is this. If you have any contenteditable fields in your
page (and we have a *lot* of them
e.g
<span contenteditable >some editable stuff</span>
and you host this page inside Visual Basic using the standard browser
control
then without the browser helper DLL attached to the page you can press
the left mouse button and 'sweep' over the text to highlight it. This
is of course a standard piece of Windows behaviour.
Now attach the helper DLL. Now, you can no longer sweep across and
highlight text. Instead, nothing happens.
However, the keyboard still allows this e.g you can press HOME and
CTRL+END to highlight text.
I have tried running up Spy++ to see if somehow there's something
weird going on with message handling but can't pin it down. The DLL
source code doesn't seem to be screwing around with messages it didn't
ought to be handling.
Can anyone suggest a way of pinning down this rather strange problem?.
I strongly suspect it is tied in with message handling/ accelerators
or something weird in this area. I can't see obvious message eating
but how Windows internally handles this I am not sure. I would assume
that the destination hWnd sees a WM_LBUTTONDOWN and then captures the
mouse and monitor WM_MOUSEMOVE messages to handle highlighting, but as
this behaviour is intrinsic to the edit control, I don't see it
documented anywhere. (of course, I assume that contenteditable text is
implemented via an edit control - I have no idea how MS are doing it
inside the browser).
Comment