[Javascript] table collapse bug in IE6?

[Paul Novitski]

Peter,

Thanks, yes, that's the technique I was using.  With Dave Lovering's 
suggestion, I'm now successfully hiding rows (and their cells' borders!) 
with this logic:

         if (bRowIsSelected)
         {
                 oRow.style.display = "block";
                 SetChildrensBorderWidth(oRow, 1);
         }else{
                 oRow.style.display = "none";
                 SetChildrensBorderWidth(oRow, 0);
         }
...
function SetChildrensBorderWidth(argParent, argBorderWidth)
{
         var aKids = argParent.childNodes;
         for (var i=0; i < aKids.length; i++)
         {
                 aKids[i].style.borderWidth = argBorderWidth;
         }
}

Paul



At 11:35 AM 3/27/2004, Peter Brunone wrote:
> > 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