Scrolling WebBroswer works, but not when it has proper DOCTYPE!

  • Thread starter Thread starter Zytan
  • Start date Start date
Z

Zytan

I can scroll a WebBrowser to the bottom like so:

if (webControl.Document != null)
webControl.Document.Body.ScrollTop = int.MaxValue;

But, if I include a proper DOCTYPE (for XHTML 1.1 DTD) like so:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML
1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

It will not work. It doesn't scroll at all. What gives?

Zytan
 
It does not work if you have a DOCTYPE at all, any DOCTYPE, even ones
that make no sense:

<!DOCTYPE html>

or

<!DOCTYPE>

So, if you make the webpage conformant, like you should, then it
cannot scroll, so you lose functionality. Great.

Zytan
 
I found a hack:

webControl.Select();
System.Windows.Forms.SendKeys.SendWait("{END}");

(For some reason SendKeys.Send() doesn't work, it throws an
exception.)
But, this has a problem: It needs to give focus to it.

Zytan
 
Another solution (almost):

webControl.Document.Window.ScrollTo(0, int.MaxValue);

But, for some reason it always scrolls one line not far enough. So,
the last line written out is not visible. Does anyone know why?

Zytan
 
webControl.Document.Window.ScrollTo(0, int.MaxValue);
But, for some reason it always scrolls one line not far enough. So,
the last line written out is not visible. Does anyone know why?
Click to expand...

MSDN claims "If the document is not long or wide enough for this to
happen, ScrollTo will scroll through the document as far as possible
in the specified direction." It almost does this. But not quite.

Zytan
 
webControl.Document.Window.ScrollTo(0, int.MaxValue);
MSDN claims "If the document is not long or wide enough for this to
happen, ScrollTo will scroll through the document as far as possible
in the specified direction." It almost does this. But not quite.
Click to expand...

Wait, it DOES work. It's just on certain occasions when the last text
written out to the webpage is a specific kind, it does not work. I am
having difficulty tracking down the root of the problem, since I can
get such text to work and not-work simultaneously depending on where I
make the call.

Regarding, this IS the solution for webpages with a proper DOCTYPE to
be able to scroll.

I'm just getting really tired of tracking down MS's bugs for the past
2 or 3 days. If all the bugs were merely my own, I'd be moving a lot
faster.

Zytan
 
Wait, it DOES work. It's just on certain occasions when the last text
written out to the webpage is a specific kind, it does not work. I am
having difficulty tracking down the root of the problem, since I can
get such text to work and not-work simultaneously depending on where I
make the call.
Click to expand...

After the last WebBrowser.Document.Write(), I call my scroll to bottom
function. Then I call it again with a button press. The first time
goes near the bottom. The second call goes right to the bottom. So,
I put a size checker in the scroll to bottom function. It appears the
size of the webpage GROWS by 30 pixels between the two calls, even
though nothing has changed in the webpage between them. This growth
explains the incorrect scrolling amount.

When I slow things down, it appears that each individual 'scroll to
bottom' after a Write() does work, the scroll bar is as far down as it
can go, and I can see the last Write() made. But, when all is done,
the very last Write() doesn't work. But, when I invoke another call
to 'scroll to bottom', it does work. Something strange is happening.
The search continues. Stay tuned.

Zytan
 
I found the culprit.

It happens ONLY when <DIV> tags are used to write out text with the
CSS style "white-space: pre;"

But, if you write out enough stuff after this the bug may or may not
appear (although it is consistent on which it chooses). My work is
required to find out exactly when and why it occurs. It appears that
this 'sets' the bug, and something else must unset it, and I am unsure
what.

My god.

First of all, the "white-space: pre;" doesn't render properly unless I
include a proper DOCTYPE. But when I include a proper DOCTYPE, it
*refuses* to scroll in the old method
(webControl.Document.Body.ScrollTop = int.MaxValue;), so I have to use
the new method (webControl.Document.Window.ScrollTo(0,
int.MaxValue);), which works except if I use "white-space: pre;" and
<DIV> at the same time.

Here's an idea for IE's developers: **Read the standards and follow
them!!!!**

Zytan
 
Forget about trying to use <PRE> instead, it introduces two carriage
returns within the <DIV> tags.

So, there's no solution but to deal with the fact that MS's IE
renderer doesn't properly render "white-space: pre;"

So, I guess I have to use &nbsp; to line things up in HTML, since
"pre" is not supported properly. I wonder how much that'll increase
the size of my log files.

Zytan
 
After the last WebBrowser.Document.Write(), I call my scroll to bottom
function. Then I call it again with a button press. The first time
goes near the bottom. The second call goes right to the bottom. So,
I put a size checker in the scroll to bottom function. It appears the
size of the webpage GROWS by 30 pixels between the two calls, even
though nothing has changed in the webpage between them. This growth
explains the incorrect scrolling amount.
Click to expand...

Ok, this is what happens, when I WebBrowser.Document.Write() some HTML
of <SPAN> or <DIV> with a CSS class that has "white-space: pre;" with
text that has at least one carriage return in it:

1. Immediately after the Write():
WebBrowser.Document.Window.Size = {Width=1325, Height=450}

2. After the Write() is done, "after some period of time":
WebBrowser.Document.Window.Size = {Width=669, Height=720}

Note that in #1, the width is very wide. WebBroser thinks the
carriage returns don't exist, and the page is very wide! (remember we
are using 'pre'.) Then, "after some period of time", it fixes it, and
puts the carraige returns in, and thus the width becomes normal, and
the height changes.

So, if you attempt to scroll to the bottom in #1, it does scroll to
the bottom of the size it THINKS it is, but as soon as it is actually
rendered, it's not far enough.

The only thing left is to define "after some period of time". #1. is
called after the Write() call. #2. is called via button in the form,
by manual click. What happens between #1 and #2? I thought maybe
it's just some time, so I waited a second in #1, and THEN scrolled to
the bottom, but no cigar (it still hasn't 'fixed' the size, yet). I
thought maybe it is the WM_PAINT message. But, I put the thread to
sleep, and waited for some time, and I still get #1 behaviour, BUT,
since I am in the main thead, and I put it to sleep, then I am
delaying WM_PAINT.

I believe I must allow WM_PAINT to render the form, then it corrects
the problem, and THEN I have to scroll to the bottom. So, I went to
use Control.Update(), but this doesn't work. It "Causes the control
to redraw the invalidated regions within its client area", which
sounds like it forces an update. But, then, Control.Refresh() claims
it "Forces the control to invalidate its client area and immediately
redraw itself and any child controls", so it sounds like the one to
use. BUT, WebBroswer.Refresh() ERASES THE CONTENTS of the control!
Microsoft, please fix these damned bugs. So far I am on a chain of 5
bugs where each led to the next.

My question:

How can I force a control to process WM_PAINT? Looks like the only
solution is DllImport to Win32's UpdateWindow().

Zytan
 
1. Immediately after the Write():
WebBrowser.Document.Window.Size = {Width=1325, Height=450}

2. After the Write() is done, "after some period of time":
WebBrowser.Document.Window.Size = {Width=669, Height=720}

Note that in #1, the width is very wide. WebBroser thinks the
carriage returns don't exist, and the page is very wide! (remember we
are using 'pre'.) Then, "after some period of time", it fixes it, and
puts the carraige returns in, and thus the width becomes normal, and
the height changes.
Click to expand...

If I put Thread.Sleep(1000) before and after the Write(), I can see
the text being rendered without any carriage returns, so WM_PAINT is
being processed (well, until the delay is so long, that the message
queue being passed for > 5 seconds, and Windows notices this [if you
let it notice by bugging the app] and the window stops updating until
the message queue resumes). And nothing is being 'corrected' even
after a whole second.

What I don't get is that after multiple Write() calls are done, "after
some period of time" the WebBrowser corrects the document. But not
before. What is "after some period of time"? I can set the delays to
5 seconds, and it still does not correct itself. So, this is not a
time issue. Something is happening, and I am not sure when it is
being triggered. Perhaps this corection is done in some event, like
DocumentCompleted. This is the only solution. But, when does that
know to be called? Why does it apparantly wait sometimes? This is
confusing.

Zytan
 
I believe I must allow WM_PAINT to render the form, then it corrects
the problem, and THEN I have to scroll to the bottom. So, I went to
use Control.Update(), but this doesn't work. It "Causes the control
to redraw the invalidated regions within its client area", which
sounds like it forces an update. But, then, Control.Refresh() claims
it "Forces the control to invalidate its client area and immediately
redraw itself and any child controls", so it sounds like the one to
use. BUT, WebBroswer.Refresh() ERASES THE CONTENTS of the control!
Microsoft, please fix these damned bugs. So far I am on a chain of 5
bugs where each led to the next.
Click to expand...

After WebBrowser.Write(), the WebBrowser.Invalidated event is NOT
raised.

Wow.

http://msdn2.microsoft.com/en-us/library/system.windows.forms.control.invalidated.aspx
"Occurs when a control's display requires redrawing."

Zytan
 
I can witness NO events being raised when the WebBroswer decides to
'fix' itself and render itself properly. Amazing. The only solution
is to NOT use "white-space: pre;" and use &nbps; instead to properly
format text. There is no way around MS's IE's rendering bug with the
"white-space: pre;" inside <DIV> or <SPAN> tags with carriage
returns. What a pain.

So, now, since I am going to NOT use "white-space: pre;", I can go
back to the original scrolling method, which does not require a proper
DOCTYPE to work:

webControl.Document.Body.ScrollTop = int.MaxValue;

Zytan
 
So, now, since I am going to NOT use "white-space: pre;", I can go
back to the original scrolling method, which does not require a proper
DOCTYPE to work:

webControl.Document.Body.ScrollTop = int.MaxValue;
Click to expand...

Sorry, the above method does NOT work with a DOCTYPE. So, the best
way is still to use the new method I found:

webControl.Document.Window.ScrollTo(0, int.MaxValue);

Which I assume works with no DOCTYPE, as well. But, you should have a
DOCTYPE, it's proper code.

Zytan
 
You must log in or register to reply here.

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Why is no viewState send to the Browser in this piece of aspx code 2
How can it work without a closing tag 2
The compiler never complains about the markup code 1
Is there any guideline in what section in aspx page where I should put my controls 1
How do I write a script that is to be run on the client side to move text from one textbox to anothe 1
newbie, trouble with doctype update 7
Is it correect to say that the div element is a control 1
css and master page problem 4

Back
Top