FLUSHing out put mid-table in IE

C

CJM

I have quite a large report, which takes a couple of minutes to run. I'd
like to show line-by-line updates as they become available, but since I'm
using IE6, Response.Flush() doesnt work.

I know that I could break the table up into a series of smaller tables, but
I prefer not to do this unless I have to - are there any other alternatives
for flushing rows of a table?

Thanks

Chris
 
B

Bob Barrows [MVP]

CJM said:
I have quite a large report, which takes a couple of minutes to run.
I'd like to show line-by-line updates as they become available, but
since I'm using IE6, Response.Flush() doesnt work.

What does the browser have to do with it?
I know that I could break the table up into a series of smaller
tables, but I prefer not to do this unless I have to - are there any
other alternatives for flushing rows of a table?
I have no trouble using Response.flush with an IE6 client.

One gotcha is that some minimum number of characters (I forget how many)
needs to be in response before the first fluxh can occur. Here is an example
that works fine in my IE6 browser:

<%
Response.Buffer=true
dim t,i,j
'build initial response to allow subsequent flushes to occur
for j = 0 to 25
Response.Write "1"
next
Response.Write "<BR>"
Response.Flush

for j = 0 to 2
'simulate long-running task (not recommended)
t=now
do until datediff("s",t,now)>=2
i=i+1
loop
Response.Write i & "<BR>"
Response.Flush
next
%>

Bob Barrows
 
C

CJM

Bob Barrows said:
What does the browser have to do with it?

Quite a lot apparently... I have read that the result produced by
Response.Flush() vary according to browser, and have subsequently proved the
same myself.

I have a report that generates a table that is 45-50 columns wide, and 200
rows long... and it takes some time to produce. Inserting a Response.Flush
in the code flushes the output to the client, but what happens then is
dependant on the browser. E.g. FF1.5.1 renders each row line by line (as
expected) but IE6 doesnt (until the closing </table> tag is generated). If
you rt-click/View Source during this period, the source indicated that the
browser is receiving the FLUSHed output from the server, but IE6 is not
rendering it.
I have no trouble using Response.flush with an IE6 client.

One gotcha is that some minimum number of characters (I forget how many)
needs to be in response before the first fluxh can occur. Here is an
example
that works fine in my IE6 browser:

I'm asking it to flush after each line, which means the buffer will have
several hundred characters in it each time, as a minimum. I assume this is
greater than the minimum required?

Thanks for the prompt response anyway Bob. Any further ideas?
 
B

Bob Barrows [MVP]

CJM said:
Quite a lot apparently... I have read that the result produced by
Response.Flush() vary according to browser, and have subsequently
proved the same myself.

I have a report that generates a table that is 45-50 columns wide,
Ah! I missed that operative word in your OP. Yes, IE refuses to "buffer" a
table element.

One way around this is via client-side code:
<%
Response.Buffer=true
%>
<html>
<head>
<script type="text/javascript">
function addRow(data)
{
var tblbody=document.getElementById("tblData").tBodies(0)
var newRow=tblbody.insertRow()
var newCell=newRow.insertCell()
newCell.innerText=data
}
</script>
</head>
<body>
<table id="tblData">
<thead>
<tr><th>Heading</th></tr>
</thead>
<tbody></tbody>
</table>
</body></html>
<%
dim t,i,j
Response.Flush

for j = 0 to 2
'simulate long-running task (not recommended)
t=now
do until datediff("s",t,now)>=2
i=i+1
loop
Response.Write "<script type=""text/javascript"">" & _
"addRow('" & i & "');</script>"
Response.Flush
next
%>
 
D

Dave Anderson

CJM said:
I know that I could break the table up into a series of smaller
tables, but I prefer not to do this unless I have to - are there
any other alternatives for flushing rows of a table?

"flushing" is the wrong word. When you use Response.Flush(), IE actually
receives the content. You want to force the browser to render a table before
it encounters </table>. I know of no way to do that. In any case, IE is
under no obligation to do so.



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.
 
C

CJM

Dave Anderson said:
"flushing" is the wrong word. When you use Response.Flush(), IE actually
receives the content.

Yeah, I'd agree with that.
You want to force the browser to render a table before it encounters
</table>. I know of no way to do that.

That is what I feared.
In any case, IE is under no obligation to do so.

IE is under few obligations to do anything useful! :)


Never mind...

Chris
 
B

Bob Barrows [MVP]

Bob said:
Ah! I missed that operative word in your OP. Yes, IE refuses to
"buffer" a table element.
Bad wording. I should have said "IE insists on buffering table elements".
 
C

CJM

Bob Barrows said:
Bad wording. I should have said "IE insists on buffering table elements".
--

No probs - I understood what you meant.

Rather than use an JS workarounds, I think I'll just accept the status quo.
Besides, I'm working on making the report smaller/quicker to run...

Thanks
 

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

Members online

Forum statistics

Threads
474,145
Messages
2,570,824
Members
47,370
Latest member
desertedtyro29

Latest Threads

Top