[Javascript] table collapse bug in IE6?

[Peter Brunone]

> Has anyone coded or run across a successful use of this technique, 
> modifying a table on the fly by hiding & showing selected rows?  If
there's 
> a working example I could look at, I'd be grateful.

Paul,

	Here's some code I use to do the hide/show rows bit in IE
(stripped of irrelevant stuff, so let me know if I accidentally took out
something you need).  For the record, I've never had problems using this
technique... But of course your circumstances may be quite different.


    function showAssignments(eventID, prevEventID) {
        var tblAssignments =
document.getElementById("tblEventAssignments");
        var trAssignments = tblAssignments.rows;

        for(var i=1;i<trAssignments.length;i++) {
            if(trAssignments[i].id.indexOf(myCriterion) >= 0) {
                trAssignments[i].style.display = 'inline';
                // Used inline because I didn't know it should have
                //  been block for <tr>, but it works fine
                }
            else {
                trAssignments[i].style.display = 'none';
                }
           }
        }

Cheers,

Peter

-----Original Message-----
From: javascript-bounces at LaTech.edu On Behalf Of Paul Novitski

Thanks for your solid comments, Dave.

>Believe me, having all the columns change width on every reselect looks
>incredibly shabby (unprofessional, etc. etc.), and this trick lets the 
>original dynamic column widths define what the subsequent table redraws

>will use -- the best of both worlds.

I agree completely.  I will tweak my code accordingly.

I have, by the way, rewritten the script to destroy & rebuild the
display 
table on each re-select, and of course the phantom borders are no longer
a 
problem.  But I'm still curious to know whether they were caused by bad 
coding by me or by Microsoft.  I've haven't seen this bug mentioned on
the net.

One clue to the nature of the problem might be that the most persistent 
phantom borders appear to originate in the initial rendering of the 
table.  When I return to the all-records view, none of the phantoms are 
visible (they've either disappeared or they're in alignment with the 
intended cell borders).

Has anyone coded or run across a successful use of this technique, 
modifying a table on the fly by hiding & showing selected rows?  If
there's 
a working example I could look at, I'd be grateful.

Paul

At 05:51 AM 3/27/2004, you wrote:
>Hmmm... most interesting.
>
>Rather than twinking about with the visibility of each div/row object,
>(which may leave the borders still showing), I'd suggest removing the
rows 
>completely which you don't want to have appear, and add them again when

>the selection criteria so indicates.  I've done this on a production 
>database-lookup utility I wrote a couple of years ago, and it works
slick 
>as snot.
>
>The only consideration is that if you've got zillions of rows/columns 
>to
>repaint, the rebuild of the ordered table may cause the screen image to

>sequentially mutate while the column widths change as new rows are 
>inserted.  To beat that problem, I start with a "show everything"
display 
>(much as you do), record the display column widths, and then force the 
>column width attribute to conform to that initial value.  That way the 
>screen doesn't writhe about as things get repositioned.  Believe me, 
>having all the columns change width on every reselect looks incredibly 
>shabby (unprofessional, etc. etc.), and this trick lets the original 
>dynamic column widths define what the subsequent table redraws will use
-- 
>the best of both worlds.
>
>The other trick which makes for a neater finished product is to have 
>two
>layers -- one visible (with a message of the sort "please wait while we

>rebuild your table image..."), and a background plane where the new
table 
>is being rebuilt.  When the onload event for the back plane object
shows 
>that the new table view is complete, simply change the z-attribute to 
>bring the back plane to the fore (and vice-versa), and voila! the
finished 
>table reappears.  A variation is to leave the original table in view
and 
>use a floating pop-up to alert the user that the new table is being 
>constructed, and then swap the top table-layer with the bottom just
after 
>you trash the pop-up.
>
>QED.
>
>-- Dave Lovering
>----- Original Message -----
>From: <mailto:paul at dandemutande.org>Paul Novitski
>
>Thanks for your suggestions, however I had earlier tried display:none 
>and found the problem of border ghosts remains.
>
>Attached is a demonstration of the problem.  (Blush: this is an old 
>workbench file, not final production code, so please excuse all the 
>wood shavings, tools lying about, and old trials commented out in the 
>mix.)
>
>I imagine that this problem might not SHOW if I use fixed column widths

>to prevent the cell borders from shifting horizontally as rows appear &

>disappear.  However, a) I want to solve the problem if I can, not just 
>work around it, and b) I balk at pre-determining table column widths --

>I'll do it if I have to for a specific purpose, such as matching a 
>table cell with a contained image of fixed dimensions, but in general 
>it feels like intruding on functionality I ought to leave up to the 
>browser so that I don't have to try to anticipate future data fill 
>needs.  The looser my control on rendering niceties, the less I have to

>go back and tweak code as conditions change.
>
>Paul