Igor's APP and BHO

[gandhi...@gmail.com]

Hallo,
opologize my bad english.
I am new in COM and BHO world. I download and start Igor's APP it works
good!
I want to communicate between my BHO and APP but I new to COM. I want
APP to change BHO buttons when surfing. I don't know how to
communicate. I need QueryInterface?

please help!

with best regards
gandhi

[Igor Tandetnik]

<gandhi...@gmail.com> wrote in message
news:1143959209.9...@u72g2000cwu.googlegroups.com

> I am new in COM and BHO world. I download and start Igor's APP it
> works good!
> I want to communicate between my BHO and APP but I new to COM. I want
> APP to change BHO buttons when surfing. I don't know how to
> communicate. I need QueryInterface?

I know of two reasonably good ways. First, you can use thread-local
storage (TLS) - see TlsAlloc et al. Implement both the BHO and the APP
in the same DLL, have a BHO allocate TLS index and store it in a global
variable. Each instance of a BHO should store enough information in TLS
for APP to find and communicate with it.

This approach relies on the observation that, even when multiple IE
instances run in the same iexplore.exe process, each one runs on its own
thread. I'm not sure if this still holds in IE7 with its tabbed
browsing. In fact, I haven't tested my APP on IE7, I don't know if it
works at all.

Second, you can do the following. Override
IHttpNegotiate::BeginningTransaction and/or OnResponse as shown in my
sample. Get IWindowForBindingUI service from the client (later versions
of my APP have a handy QueryServiceFromClient method), and call
GetWindow on it. This gives you an HWND of the document object.

A BHO can get the same window by calling IWebBrowser2::get_Document,
querying the resulting pointer for IOleWindow and calling GetWindow. One
can associate arbitrary information with an HWND using SetProp and
GetProp APIs. So again, a BHO stores enough information there for the
APP to later find it, and the APP later picks it up. This approach
probably has a better chance to still work in IE7.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

[gandhi...@gmail.com]

Thank you. I tried this and it works ok for first page. second page
always return NULL in GetWindow. Any idea why?

thank for helping
gandhi

[Tal Moshaiov]

Hi,

I'm not much of an expert on this, but I think that the first
request/response is made on the main thread and the rest are made on
the worker thread.
I read Igor's post on this in another thread that suggests using
switch/continue to get back to the main thread. as I'm having a similar
issue, I tried it myself with no luck (perhaps I misused it).
If only there was a way to preserve state between repeatative sink
calls . . .

Igor seems to be the expert on this. Perhaps we could help us both ?

- Tal

[Igor Tandetnik]

<gandhi...@gmail.com> wrote in message
news:1144320324.8...@z34g2000cwc.googlegroups.com

> Thank you. I tried this and it works ok for first page. second page
> always return NULL in GetWindow. Any idea why?

Where are you calling it from? Make sure to do it from
BeginningTransaction or OnResponse. These are always called on the main
thread, pretty much any other method may be called on the worker thread
where IWindowForBindingUI won't work.

[Tal Moshaiov]

Thanks Igor,
I'm calling it from OnResponse.
When I issue a GetCurrentThread() from the OnResponse I get different
thread IDs each time.

- Tal

[Tal Moshaiov]

gandhi ,

per your offline email - since each call to OnResponse() is issued on a
different thread - I guess that TLS won't help either.

I have no idea how to preserve state between successive calls to
OnResponse() (within the same IE page).

I guess Igor will save the day again?

- Tal

[Igor Tandetnik]

"Tal Moshaiov" <mosh...@gmail.com> wrote in message
news:1144325868.6...@v46g2000cwv.googlegroups.com

> I'm calling it from OnResponse.
> When I issue a GetCurrentThread() from the OnResponse I get different
> thread IDs each time.

I've tested the Switch / Continue approach - it appears to work. I'm
calling Swich in OnResponse and reliably getting IWindowForBindingUI in
Continue. Make sure to set grfFlags field to PD_FORCE_SWITCH.