Results 1 to 10 of 10

Thread: Problem with column resize in DwtListView

Hybrid View

  1. #1
    Join Date
    Oct 2005
    Location
    Switzerland
    Posts
    54
    Rep Power
    10

    Default Problem with column resize in DwtListView

    I have a strange problem regarding sashes automatically created by DwtListViews. I have attached the full code of my example and a screenshot to illustrate the problem and for anybody who wants to try it out.

    The situation is the following:
    I have a DwtTree and a DwtListView (4 columns) separated by a DwtSash (HORIZONTAL_STYLE). In addition, I have some existing raw HTML in which I put the Dwt widgets. The raw HTML is the following (generated by the jsp).

    Code:
    <body>
      <table>
          <tr>
              <td>LALALALALALALALALALALALALALALALALA</td>
              <td>
                  <p>A nice little paragraph before the wflow</p>
                  <div id="WorkflowDiv"></div>
                  <p>The footer information</p>
              </td>
          </tr>
      </table>
    </body>
    The widgets are "put" in the div element with id "WorkflowDiv" as follows:
    Code:
    document.getElementById("WorkflowDiv").appendChild(this._app.getHtmlElement());
    
    where this._app is the DwtShell of the example.
    The whole thing displays correctly in the browser. However, when I click on one of the columns to resize it, the black line representing the sash between the 2 columns is shifted to the right. Actually, it is shifted to the right, the size of the first cell in the raw HTML. That is, if the first cell of the raw html table of my example has a width of 100px, when you click on the sash of the listview to resize your column, you'll have the black line display 100px to the right of the place you clicked.

    How can I solve this ? Is this a bug ?

    If you check out my screenshot, I clicked where I put the "red 1" and the black line appears "x" number of pixels to the right. The value of x, is the value of the first cell containing the "LALALA" text.
    Attached Files Attached Files

  2. #2
    Join Date
    Oct 2005
    Location
    Switzerland
    Posts
    54
    Rep Power
    10

    Default

    Any thoughts by anybody ?

    I believe this is a bug of the DwtListView...

  3. #3
    Join Date
    Aug 2005
    Location
    San Mateo, CA
    Posts
    4,789
    Rep Power
    19

    Default

    I think it's a bug. We've seen something similar if you resize certian columns in the mail client. Just haven't had the chance to dig into this yet.
    Looking for new beta users -> Co-Founder of Acompli. Previously worked at Zimbra (and Yahoo! & VMware) since 2005.

  4. #4
    Join Date
    Nov 2005
    Posts
    5
    Rep Power
    9

    Default

    I found the bug. There are 2 problems I see. At the end of DwtListView.prototype._handleColHeaderResize ()
    it should determine where to redraw the column resize sash by subtracting the Dwt parent widget HTML element's X (relative to the window) from the mouse event X (relative to the window too), the first problem is this method is subtracting parent HTML element's offset relative to its parent (when the parent widget is absolute instead of static style) instead. The 2nd problem I see is that the DvListView widget (which has a static style) needlessly overrides DwtListView's _getParentForColResize() method so that the method returns its parent widget, a DwtTabView (absolute style). These two factors combined cause the offset calculation to be off, in this case it's off by the width of the non-Dwt HTML div into which the tab view is set child of.

    I don't see why anyone want to override _getParentForColResize(). So I see 2 fixes here:

    1. Do not override _getParentForColResize() under any circumstances.
    2. Change DwtListView.prototype._handleColHeaderResize () so it always calculate offsets relative to the window, i.e. the last 3 lines are changed to :
    var parent = this._getParentForColResize();
    var loc = Dwt.toWindow(parent.getHtmlElement(), 0 ,0);
    Dwt.setLocation(this._headerSash, ev.docX-loc.x);

    from
    var parent = this._getParentForColResize();
    var loc = parent.getLocation();
    Dwt.setLocation(this._headerSash, ev.docX-loc.x);


    Either of these 2 fixed the problem for me, and I applied both.
    jpenguin

  5. #5
    Join Date
    Sep 2005
    Location
    Sunnyvale, CA
    Posts
    269
    Rep Power
    10

    Default

    jpenguin, thanks for the fix! I tested it out with the web client and doesnt seem to break anything (i say "break" b/c we dont see this bug in the mail client). Although, I do recall seeing this bug when creating new list views but dont remember how i avoided it

    Heladito, does this fix work for you as well?

  6. #6
    Join Date
    Oct 2005
    Location
    Switzerland
    Posts
    54
    Rep Power
    10

    Default

    Yep, it works for me too

    Thanks a lot jpenguin

Similar Threads

  1. Zimbra, WM5.0, AS + problem with regional fonts
    By wojo2000 in forum Zimbra Mobile
    Replies: 7
    Last Post: 06-25-2007, 01:04 AM
  2. Is it started or not
    By kwelipatton in forum Installation
    Replies: 10
    Last Post: 03-28-2006, 10:11 PM
  3. HELP! DwtListView Header Problem...
    By sirick in forum Developers
    Replies: 7
    Last Post: 10-29-2005, 06:58 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •