Best regards
> First of all, can we modify/custom URLPresenter's context menus (
> which is IE one by default ) to add new menuitem to trigger my own
> search function etc ?
I'm not quite sure whether it's possible to customize the default menu
dynamically. You can do it globally (see
http://msdn.microsoft.com/en-us/library/aa741313(VS.85).aspx#Controlling_the_Cont
for more information) by tweaking the Registry Entries.
You can however replace it completely.
URLPresenterWithContextMenu (in package "US Internet Explorer
Extensions") allows you to control which context menu is displayed in a
WebControl:
* If the presenters view #allowContextMenu aspect is false no
context menu will be shown. Neither a custom one nor the default one.
* If the presenters view #allowContextMenu aspect is true it depends
on #contextMenu. If #contextMenu is not nil it will be displayed. If it
is nil the default one will be used.
Behind the scenes this presenter implements the
IDocHostUIHandlerDispatch interface to get queries for some UI events.
The interesting one here is ShowContextMenu() which allows you to
allow/prevent the display of the default context menu. I'm using this
method for the logic using #allowContextMenu and #contextMenu.
However for using this presenter no digging into COM is needed. Simply
use #allowContextMenu and #contextMenu as written above.
You can download the most recent version of my goodies here:
http://readthesourceluke.blogspot.com/
Hope this helps.
CU,
Udo
Thanks again for your great help to fill in the missing stones, it
would be better if the #todo are implemented in futher update versions
of your packages.
BTW, another question, could I get the selected text in the browser
from the underlying MSHTML controller ( via IWebBrowser2::get_Document
to get IHtmlDocument2 ?)
Best reguards.
URLPresenter>>documentSelection
| browser |
browser := self view controlDispatch.
^browser document selection createRange text.
It's just a quick workout, I think, without creating new
ImpType/IDispatch objects. Formal resolution might be needed.
Best regards.
> Thanks again for your great help to fill in the missing stones, it
> would be better if the #todo are implemented in futher update versions
> of your packages.
The #todo Symbol and the comment are misleading - my mistake. Returning
E_NOTIMPL is perfectly legal for the non-implemented methods in this
interface. It simply tells the caller to use the default processing.
So we only return S_OK for the context menu stuff where we really do
something.
> BTW, another question, could I get the selected text in the browser
> from the underlying MSHTML controller ( via IWebBrowser2::get_Document
> to get IHtmlDocument2 ?)
Just uploaded a new version. URLPresenter now has getSelectedText
methods for your convenience.
CU,
Udo
> It's just a quick workout, I think, without creating new
> ImpType/IDispatch objects. Formal resolution might be needed.
This is fine - I'm doing nothing else in my goodies. However you should
wrap this in an exception handler as the Control throws errors. An
example is calling this method w/o selected text in the browser. This
sometimes throws errors as well.
CU,
Udo