I've been experimenting with a version that doesn't use the PIA. This mainly involves defining a bunch of additional COM interfaces so it's fairly tedious.

I have it working to the extent that the HtmlEditor dll compiles, and the demo app runs although I've temporarily commented out some of the functions. However, I'm not sure whether this is worth pursuing. Here are some findings:

Advantages

The non-PIA version loads a bit quicker. This is mainly a start-up issue. Once an instance of the control has been displayed, it's very quick to display further instances with or without the PIA.

You don't have to distribute mshtml.dll

You have more control, you can tweak the definitions to fix stuff.

It uses less memory. However, not by as much as I'd expected. Looking at the mem. usage in Task Manager shows that the non-PIA version uses typically between 2 and 4 MB less RAM. However, even the non-PIA version climbs to around 20MB total when you start trying out all the features, esp. print preview, so it is not that much proportionately.

Disadvantages

The actual HtmlEditor DLL is larger. Currently 124K vs 84K, but there are quite a few definitions to come.

Manually re-defining what is already in the PIA is quite an effort. It only makes sense on the basis that you need just a subset of what is in the PIA. If you make extensive use of the DOM that may be quite a large number of definitions. If you end up using the mshtml PIA in your app, then the fact that the control doesn't use it gains you nothing.

It doesn't seem to make any difference to things like the way focus works, or the puzzling (handled) exception you get when closing a document.

Overall I'm not sure whether to go further down this path or not.

Tim

Tim: Take a look at this tool COM to .NET from Aurigma. It helps with importing type libraries and it creates the C# source for you.
[www.aurigma.com]

you can download the beta for free.

Tim,

I agree: I went down the route of trying to manually redefine all the COM interfaces I needed: this became almost impossible because of the dependencies with other interfaces. Half the time I found that there was yet [i]another [\i] feature in MSHTML I needed to use and needed to redefine it. I ended up on a hiding to nothing.

The main advantage of programming-out the MSHTML PIA is that the distribution becomes easier, however the PIA squashes up to 1.6Mb, which isn't too bad.

I've now completed the mshtml-free version to the point where the demo app runs just the same, except for the table insert. I was interested to see if would impact the performance of the recursive ParseNodes routine. I took out Console.WriteLine as that is always slow, loaded a moderate-sized document and timed ParseNodes. The performance was near-identical, confirming I think that there is no point in eliminating mshtml, unless you have a special reason.

Tim

Special reason!

Iam using "no touch deployment" downloading of windows forms clients, and the downloading of microsoft.mshtml.dll is really heavy on a 512kb connection. So i have a special reason to have a light weight htmlediting control.

PS:Is it possible to test your mshtml-free version?

Regards,

Mats-Erik

Sure.

I've uploaded it to:

[www.netcomuk.co.uk]

This version is a bit out-of-date now, not thoroughly tested, and probably full of Debug.Writeline statements, but by all means have a look.

Tim

Hi Tim,

Is your htmleditor_no_pia.zip file still available for download? I'd like to take a look if it's still available.

Thanks, ramida

Sure, it is here:

[www.itwriting.com]

If you improve it, please let us know.

Tim

Tim, thanks a lot!

ramida

The UberBuild doesn't require the PIA either...

needA the mshtml . dll please

Hey tim,
how are you
i want to implement table management in html without using mshtml so i wont be dependent on mshtml?
Can u guide me please
or do u have any reference
thanx
waiting!!!

I'm pretty busy at the moment so I'm unlikely to get to it soon.

It is mainly a matter of adding COM interop definitions for the calls you need. Most of these are straightforward. Use the header files in the Windows SDK to get the C versions, then convert them to C#.

Tim