HtmlEditor : Phorum 5
This is the discussion forum for the HtmlEditor. See also the HtmlEditor home page, where you can download the control, and the Documentation Wiki, a collaborative project for documenting the control.
Using document or window objects on other threads
Posted by: BladeMF (---.unitednetworx.com)
Date: Wednesday, 10-Jan-2007, 09:46:41
I have a problem casting the document object to IHTMLDocument on threads other than the main thread. I get an exception, saying that (for example) the HTMLDocumentClass object does not support the IHTMLDocument interface with HRESULT E_FAIL (rather than E_NOIMPL)...
I get the same with the Window object and the IElementBehaviorSite objects.
Any ideas?
I get the same with the Window object and the IElementBehaviorSite objects.
Any ideas?
Re: Using document or window objects on other threads
Posted by: BladeMF (---.unitednetworx.com)
Date: Wednesday, 10-Jan-2007, 09:51:21
Actually it throws E_NOINTERFACE
Re: Using document or window objects on other threads
Posted by: Tim (---.gotadsl.co.uk)
Date: Wednesday, 10-Jan-2007, 17:19:47
A couple of thoughts.
First, COM threading is a big subject in its own right. See p 275-282 in Adam Nathan's book.
Second, are you checking that the document is fully loaded?
Tim
First, COM threading is a big subject in its own right. See p 275-282 in Adam Nathan's book.
Second, are you checking that the document is fully loaded?
Tim
Re: Using document or window objects on other threads
Posted by: BladeMF (---.btc-net.bg)
Date: Wednesday, 10-Jan-2007, 20:42:06
Yep, the doc is all okay.
I discovered an interesting thing, though: If you run a new thread, and intend to call IHTMLWindow there, it *needs* to be STA thread (when you create the thread, you must set the apartment state, which is one-liner). All of this is cool and stuff, doc and window resolved, but the IElementBehaviorSiteOM just doesn't want to cast. And I actually need this interface and noticed the problem with the window on the way.
The really strange thing is, that I have and assembly, that is older, and does not have the problem. There I use a BackgroundWorker to do the async stuff, and it resolved the problem back then. The problem is that I don't see any difference in the old code and current code, but it *must* be something I did somewhere.
Actually it bothers me more that I don't understand why, than the fact I have this problem. How come it worked when I put the worker and then stopped working (with the worker still there)??
Oh, and I don't have the Adam Nathan's book
I discovered an interesting thing, though: If you run a new thread, and intend to call IHTMLWindow there, it *needs* to be STA thread (when you create the thread, you must set the apartment state, which is one-liner). All of this is cool and stuff, doc and window resolved, but the IElementBehaviorSiteOM just doesn't want to cast. And I actually need this interface and noticed the problem with the window on the way.
The really strange thing is, that I have and assembly, that is older, and does not have the problem. There I use a BackgroundWorker to do the async stuff, and it resolved the problem back then. The problem is that I don't see any difference in the old code and current code, but it *must* be something I did somewhere.
Actually it bothers me more that I don't understand why, than the fact I have this problem. How come it worked when I put the worker and then stopped working (with the worker still there)??
Oh, and I don't have the Adam Nathan's book
RESOLUTION
Posted by: BladeMF (---.unitednetworx.com)
Date: Thursday, 11-Jan-2007, 12:15:31
Okay, problem resolved.
It turns out that all IElementBehavior* interfaces are not present in the registry (which is quite odd). After I noticed that IElementBehaviorSite didn't have the described problem and wondered why is this. After two days of reading I figured out a lot about COM threading and apartments, and it says there that if you do cross thread calls to COM objects, they need to be registered. I thought that all were registered and thought nothing more of it. But after reaching the edge of desperation, decided to look in the registry and what do you know - IElementBehaviorSiteOM wasn't there, but IElementBehaviorSite was! And the specified typelibrary was my assembly.
So, I redefined the interface in my code (in my MsHTML2 namespace for redefined interfaces) and voila - it works.
I thing the STA requirement on the thread still stands though.
It remains to be answered why, the hell, these interfaces aren't defined in the registry, but the normal interfaces (like IHTMLWindow) are??
By the way, I found a very nifty program Lutz Roeder's .NET Reflector, you might want to check it out - it decompiles .NET assemblies and shows the code There's some very interesting stuff in the stock .NET library assemblies.
Cheers.
It turns out that all IElementBehavior* interfaces are not present in the registry (which is quite odd). After I noticed that IElementBehaviorSite didn't have the described problem and wondered why is this. After two days of reading I figured out a lot about COM threading and apartments, and it says there that if you do cross thread calls to COM objects, they need to be registered. I thought that all were registered and thought nothing more of it. But after reaching the edge of desperation, decided to look in the registry and what do you know - IElementBehaviorSiteOM wasn't there, but IElementBehaviorSite was! And the specified typelibrary was my assembly.
So, I redefined the interface in my code (in my MsHTML2 namespace for redefined interfaces) and voila - it works.
I thing the STA requirement on the thread still stands though.It remains to be answered why, the hell, these interfaces aren't defined in the registry, but the normal interfaces (like IHTMLWindow) are??
By the way, I found a very nifty program Lutz Roeder's .NET Reflector, you might want to check it out - it decompiles .NET assemblies and shows the code
There's some very interesting stuff in the stock .NET library assemblies.Cheers.
Re: RESOLUTION
Posted by: Tim (---.gotadsl.co.uk)
Date: Thursday, 11-Jan-2007, 12:39:12
Interesting, thanks.
> By the way, I found a very nifty program Lutz Roeder's .NET Reflector, you
> might want to check it out - it decompiles .NET assemblies and shows the
> code There's some very interesting stuff in the stock .NET library
> assemblies.
I agree; I took a look at the .NET 2.0 webbrowser control and was amazed at its complexity.
Tim
> By the way, I found a very nifty program Lutz Roeder's .NET Reflector, you
> might want to check it out - it decompiles .NET assemblies and shows the
> code
There's some very interesting stuff in the stock .NET library > assemblies.
I agree; I took a look at the .NET 2.0 webbrowser control and was amazed at its complexity.
Tim