show HTML text

Hi,

I'm trying to show a string of HTML text in a window, using the normal MVP.

Had a good look at the web browser example and the URLpresenter that is used
in there, but that presenter requires a URL address as the value. I don't
want that, I just want the HTML text to be parsed.

I've been messing around with the IWebBrowser classes, but they all seem to
be based on the fact that you give it a URL and then based on that it
fetches the HTML file and displays it. I could of course output my HTML
string to a file in a temporary directory and then point the URL at that,
but I find that a bit ugly.

Anybody any suggestions?

Cheers,

Ted

Ted,

One thing I noticed that OA does is to use the "about:" prefixed to an HTML
string as the URL.  There are some limitations to that, although I don't recall
what they are offhand.  Another thing I've done is to generate the interfaces
for MSHTML (which results in package of about 8MB!).

Of those extremes, I'd go with the "about:" approach until it proves
inadequate.

Don

"Ted Bracht" <[hidden email]> wrote in message
news:3c5b3912$1@tobjects....

"Don Rylander" <[hidden email]> wrote in
message news:3c5adc5c$0$79562$[hidden email]...
>
> One thing I noticed that OA does is to use the "about:" prefixed to an
HTML
> string as the URL.  There are some limitations to that, although I don't
recall
> what they are offhand.

One can only pass a very limited amount of text, about 508 characters I
think. Presumably this is 508 bytes plus four for a 32-bit length field =
512 in total. C programmers are so predictable :-)

When the limit is exceeded, the browser just ignores the request.

This limit is very low, so it just about suffices for the "Tip of the day"
window, but not much else.

>...Another thing I've done is to generate the interfaces
> for MSHTML (which results in package of about 8MB!).

Indeed. The results are indeed vast - there are hundreds of intefaces, some
of which have hundreds of methods. I would suggest generating individual
interfaces as required. Alternatively (if one has a machine of sufficient
power) generate them all, and then rely on the image stripper to remove all
those that are not used. I haven't tried it, but I suspect it will do a
pretty good job.

Regards

Blair

Blair & Ted

"Blair McGlashan" <[hidden email]> wrote in message
news:a3en3s$177ruk$[hidden email]...
[...]
> One can only pass a very limited amount of text, about 508 characters I
> think. Presumably this is 508 bytes plus four for a 32-bit length field =
> 512 in total. C programmers are so predictable :-)
>
> When the limit is exceeded, the browser just ignores the request.
>
> This limit is very low, so it just about suffices for the "Tip of the day"
> window, but not much else.

IIRC, it's surprisingly close to 2K (in the 1500- to 1800-character range, at
least on Windows 2000 with IE 5.5 sp2), so it's actually more useful than you
might expect.  It was big enough that I was lulled into a false sense of
complacency by it when I was doing some initial playing around with an
application that needed an HTML viewer.  Also, my experience with passing it a
string that was too long was that it just truncated the page.  The fact that it
was kind enough to assume the closing body and html tags served to mask the
problem for a while.

I ultimately did take the brute force "generate everything" approach to MSHTML,
and I can attest to the fact that the image stripper does an *excellent* job of
removing superfluous junk.  The only annoying bit about working with huge
packages like that is the time it takes to load one into a new image.  If it's
saved in the image, the effect on Dolphin's start-up time is barely noticeable.

Don

>
> Regards
>
> Blair
>
>

I did this in VisualAge.  You have to get the Document COM Object from the
browser, then use the write: and/or writeln: method on that object.

I even wrapped stream protocol around that, allowing printOn: kind of logic
onto the Document.

A quick glace at the web browser object, it seems they have not wrapped any
of the DHTML model.  That is what you would have to do.  It is listed as
Microsoft HTML Object Library.  I'm giving it a whirl to see what happens.

jlo

"Ted Bracht" <[hidden email]> wrote in message
news:3c5b3912$1@tobjects....
> Hi,
>
> I'm trying to show a string of HTML text in a window, using the normal
MVP.
>
> Had a good look at the web browser example and the URLpresenter that is
used
> in there, but that presenter requires a URL address as the value. I don't
> want that, I just want the HTML text to be parsed.
>
> I've been messing around with the IWebBrowser classes, but they all seem
to

Ted -

I wrapped the COM library I mentioned in the previous message using the
defaults, then changed the method IWebBrowser>>#document to:

document
"Answer the <IDispatch> value of the 'Document' property of the receiver.
Helpstring: 'Returns the active Document automation object, if any.'"
| answer |

answer := IDispatch newPointer.
self get_Document: answer.
^MSHTMLDispHTMLDocument on: answer asObject



This gave me and object I could use the write: and writeln: method on.

HTH -

jlo


"Jeffrey Odell" <[hidden email]> wrote in message
news:3c5b656d@tobjects....
> I did this in VisualAge.  You have to get the Document COM Object from the
> browser, then use the write: and/or writeln: method on that object.
>
> I even wrapped stream protocol around that, allowing printOn: kind of
logic
> onto the Document.
>
> A quick glace at the web browser object, it seems they have not wrapped
any don't
> > want that, I just want the HTML text to be parsed.
> >
> > I've been messing around with the IWebBrowser classes, but they all seem
> to
> > be based on the fact that you give it a URL and then based on that it
> > fetches the HTML file and displays it. I could of course output my HTML
> > string to a file in a temporary directory and then point the URL at
that,

"Don Rylander" <[hidden email]> wrote in
message news:a3er6m$17hckc$[hidden email]...
> Blair & Ted
>
> "Blair McGlashan" <[hidden email]> wrote in message
> news:a3en3s$177ruk$[hidden email]...
> [...]
> > One can only pass a very limited amount of text, about 508 characters I
> > think. Presumably this is 508 bytes plus four for a 32-bit length field
=
> > 512 in total. C programmers are so predictable :-)
> >
> > When the limit is exceeded, the browser just ignores the request.
> >
> > This limit is very low, so it just about suffices for the "Tip of the
day"
> > window, but not much else.
>
> IIRC, it's surprisingly close to 2K (in the 1500- to 1800-character range,
at
> least on Windows 2000 with IE 5.5 sp2), so it's actually more useful than
you
> might expect.  It was big enough that I was lulled into a false sense of
> complacency by it when I was doing some initial playing around with an
> application that needed an HTML viewer.  Also, my experience with passing
it a
> string that was too long was that it just truncated the page.  The fact
that it
> was kind enough to assume the closing body and html tags served to mask
the
> problem for a while.

Under IE6 on Windows XP the limit is definitely 508 characters (this is
easily tested by extending one of the "tips" of the day a bit). Perhaps they
fixed the buffer overrun :-).

Regards

Blair

On Fri, 1 Feb 2002 12:20:11 -0600,
Don Rylander <[hidden email]> wrote:
> Ted,
>
> One thing I noticed that OA does is to use the "about:" prefixed to an HTML
> string as the URL.  There are some limitations to that, although I don't recall
> what they are offhand.  Another thing I've done is to generate the interfaces
> for MSHTML (which results in package of about 8MB!).

This sounds as if there was an automated way of generating
interfaces to whatever-do-you-want-to-call-them-today components.
How can I do this?

s.

Blair,
"Blair McGlashan" <[hidden email]> wrote in message
news:a3f6la$184uq8$[hidden email]...
[...]
> Under IE6 on Windows XP the limit is definitely 508 characters (this is
> easily tested by extending one of the "tips" of the day a bit). Perhaps they
> fixed the buffer overrun :-).
That's a nice way to put it; even more likely, I simply didn't recall
correctly! :-)

Don
>
> Regards
>
> Blair
>
>

Re: limits on about: - the method I've described above removes that problem.
I've written a lot of data via the Document object from VisualAge.

jlo

"Jeffrey Odell" <[hidden email]> wrote in message
news:3c5b656d@tobjects....
> I did this in VisualAge.  You have to get the Document COM Object from the
> browser, then use the write: and/or writeln: method on that object.
>
> I even wrapped stream protocol around that, allowing printOn: kind of
logic
> onto the Document.
>
> A quick glace at the web browser object, it seems they have not wrapped
any don't
> > want that, I just want the HTML text to be parsed.
> >
> > I've been messing around with the IWebBrowser classes, but they all seem
> to
> > be based on the fact that you give it a URL and then based on that it
> > fetches the HTML file and displays it. I could of course output my HTML
> > string to a file in a temporary directory and then point the URL at
that,

Hi Don and Blair,

"Blair McGlashan" <[hidden email]> wrote in message
news:a3f6la$184uq8$[hidden email]...
> "Don Rylander" <[hidden email]> wrote in
> message news:a3er6m$17hckc$[hidden email]...
> > Blair & Ted
> >
> > "Blair McGlashan" <[hidden email]> wrote in message
> > news:a3en3s$177ruk$[hidden email]...
> > [...]
> > > One can only pass a very limited amount of text, about 508 characters
I
> > > think. Presumably this is 508 bytes plus four for a 32-bit length
field range,
> at
> > least on Windows 2000 with IE 5.5 sp2), so it's actually more useful
than
> you
> > might expect.  It was big enough that I was lulled into a false sense of
> > complacency by it when I was doing some initial playing around with an
> > application that needed an HTML viewer.  Also, my experience with
passing
> it a
> > string that was too long was that it just truncated the page.  The fact
> that it
> > was kind enough to assume the closing body and html tags served to mask
> the
> > problem for a while.
>
> Under IE6 on Windows XP the limit is definitely 508 characters (this is
> easily tested by extending one of the "tips" of the day a bit). Perhaps
they
> fixed the buffer overrun :-).

Thanks alot for your suggestions. Using the 'tip of the day' approach I
managed to get the first 2060 characters of an HTML document displayed. It
just chops off the rest, so I'll fiddle around a bit to have it chop off at
a whole word and then insert a hyperlink for '<more>'.

BTW, I did not get the AXValueConvertingControlSite.Default view to work,
that just always shows the progId(?). SO I had to copy the Tip of the Day
subview. When resizing that (layoutmanager - borderlayout - arrangement:
center) it took almost 100% of the cpu for about 10 minutes until the view
composer reported 'recursion too deep' error. But it'd done the job and it
all works now.

>
> Regards
>
> Blair
>
>
Thanks,

Ted

Ted,
"Ted Bracht" <[hidden email]> wrote in message
news:3c60230d$1@tobjects....
[...]
Having grown tired of trying to guess how I handled this problem, I actually
went back and looked!  I had ended up using the DHTML Edit Control, which wants
to use parts of MSHTML, but you could probably work around that by hand or just
generating a couple of interface classes.  It looks like all I ended up using
from MSHTML was the IHTMLDocument2 interface, and that only for a few methods.
All I wanted to do was set the string contents of the document, much like you
can do with the "about:..." approach.  The advantage here is that, while you
are dependent on having IE 5 or greater, the capabilities are more dependable
across different system configurations.  I had no problems with document
truncation on any of the configurations I tested (Win 2K or 98 with IE5.5 or
6--I haven't tried it on XP yet, though).  Try generating the interfaces from
the component called DHTML Edit Control for IE5, which should be found in
dhtmled.ocx somewhere on your system (assuming you have at least IE5).  The
resulting package is only about 84K (as opposed to over 7MB for MSHTML).  It
might also be worth generating IHTMLDocument2 and its superclass IHTMLDocument,
but if all you're doing is putting HTML strings into it, you shouldn't need
much more; generating the full document model was definitely overkill for my
purposes.

A couple further caveats: (1) There is some latency between the time you stuff
the string into the document and the time the document is fully created and
available for use.  I'm not sure of the best way to deal with that.  (2) Each
time you replace the document with an HTML string, the control creates a new
document.  There might be a way around that, but it wasn't really a problem for
me, so I didn't check into it.

HTH

Don

1) The latency, I believe, is that the call to navigate or write to the
document object returns immediately, and the HTML renders in another thread.
We had to handle the "navigateComplete" (not sure that is the exact name)
event to know when it was done.

2) True, and it does not appear in History list either.  OK if you don't
want to have the user use "Back" function, otherwise I'm not sure how to
handle it.

jlo

"Don Rylander" <[hidden email]> wrote in
message news:3c600103$0$79564$[hidden email]...
> Ted,
> "Ted Bracht" <[hidden email]> wrote in message
> news:3c60230d$1@tobjects....
> [...]
> Having grown tired of trying to guess how I handled this problem, I
actually
> went back and looked!  I had ended up using the DHTML Edit Control, which
wants
> to use parts of MSHTML, but you could probably work around that by hand or
just
> generating a couple of interface classes.  It looks like all I ended up
using
> from MSHTML was the IHTMLDocument2 interface, and that only for a few
methods.
> All I wanted to do was set the string contents of the document, much like
you
> can do with the "about:..." approach.  The advantage here is that, while
you
> are dependent on having IE 5 or greater, the capabilities are more
dependable
> across different system configurations.  I had no problems with document
> truncation on any of the configurations I tested (Win 2K or 98 with IE5.5
or
> 6--I haven't tried it on XP yet, though).  Try generating the interfaces
from
> the component called DHTML Edit Control for IE5, which should be found in
> dhtmled.ocx somewhere on your system (assuming you have at least IE5).
The
> resulting package is only about 84K (as opposed to over 7MB for MSHTML).
It
> might also be worth generating IHTMLDocument2 and its superclass
IHTMLDocument,
> but if all you're doing is putting HTML strings into it, you shouldn't
need
> much more; generating the full document model was definitely overkill for
my
> purposes.
>
> A couple further caveats: (1) There is some latency between the time you
stuff
> the string into the document and the time the document is fully created
and
> available for use.  I'm not sure of the best way to deal with that.  (2)
Each
> time you replace the document with an HTML string, the control creates a
new
> document.  There might be a way around that, but it wasn't really a
problem for
> me, so I didn't check into it.
>
> HTH
>
> Don
>
>