Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    TextItem 100% + IButton = impossible?!

    Guys, I think I am missing something or something wrong with SGWT.

    I want the following layout:

    My title: [_______________________] [ OK ]

    Here I want input widget take all the possible width, so I can resize the page horizontally and "My title" with "OK" button will be on left and right sides respectively.

    I've put TextItem into a dymanic form, then put dynamic form with an IButton into HLayout. Simple and a straightforward. You think it is working? No way! I've spent 2 hours banging my head in this, and still can not get it (kudos to ultra-slow Google's GWT compiler taking all my time basically).

    Most interesting, when I am trying — textItem.setWidth("*"); form.setColWidth(1, "100%"); — it renders me something nearly 30% per 70% and when I resize the window to small one, text input stays no smaller than around 500px width.

    I mean, it works like in a voodoo random way... :-(
    Anyone can help here, please?

    Yes, I saw an example of showcase for spanning (http://www.smartclient.com/docs/6.5....columnSpanning) but there are no any button near the form and form is fixed width. Anyone can make form 100% width and try to place button on the right side near the form in order button to be all the time on a right side while text input take all possible width, please?..

    Thanks.
    Last edited by shourisha; 28 May 2009, 00:08.

    #2
    Read the Form Layout overview linked pervasively throughout DynamicForm. Looks like you don't understand that there are 3 columns to your form, for starters.

    Comment


      #3
      Stick to a form for layout you are looking for. Here is the modified sample to work like you want. Read up on columns, layout, sizing, column spanning, etc. in the docs and you'll see how this works and how you can build pretty complex forms.

      Note this sample is for native SmartClient but should be doable in SmartGWT the same way.

      Code:
      isc.DynamicForm.create({
          width: "95%",
          numCols: 3,
          colWidths: [60, "*", 60],
          border:"1px solid blue", padding:5,
          canDragResize:true, resizeFrom:["R"],
          fields: [
              {name: "subject",
               title: "Subject",
               type: "text",
               width: "*"
              },
              {name: "button",
               title: "press",
               type: "button", 
               startRow: false
              },
              {name: "message",
               type: "text",
               length: 5000,
               showTitle: false,
               colSpan: 2,
               width: "*"
              }
          ]
      });

      Comment


        #4
        David, thanks for your reply.
        Well, I've *read* docs and sorry that I did not showed that I was using three columns. :) But it still does not working at all. However I am not sure on what layers is a problem: PEBKAC (probably, hence asking for help), SmartGWT or SmartClient?

        OK, here are my settings for the form:
        .setNumCols(3); — means form has 3 cols, right?
        .setColWidths(10, "*", 10); — means first column is going 10x, second fills everything possible and last is also 10px, right? (fixedColWidths is default, to false)
        .setWidth("100%"); — means I want my form to be wide from start to end.
        .setResizeFrom("R"); — form resizes to the right side.

        Now, I've created two form items, one takes two columns in a form table:
        1. TextItem. Nothing special, width — "*". Means, I want input field fill entire possible space. Title: "Hello, isomorphic", set wrapping to False.
        2. ButtonItem (hence IButton is impossible to put into a dynamic form for some reasons). Width: 150px.

        What I am expecting:
        1. Title "Hello, isomorphic" will make cell wider than 10px, and will take all text widh. Correct?
        2. Input widget fills second column completely.
        3. Third column gets wider than 10px as well, because of button item does that.

        Maybe better to .setColWidth(1, "*", 1); after all.

        What I am getting:
        1. Title takes about 35% of space and gets resized by a percentage, if I resize browser.
        2. Input itself takes about 80% and is resized. But when I resize my browser from 2000 px width to like 700px, input suddenly stops to resize and sticks unchanged, generating me a horizontal scrollbar in a browser... (no idea why).
        3. Button (last one at the right side) is OK, but gets shifted out of the browser because text input refuses to get smaller than ~650px.

        I mean... why? :-) It feels like anything I've set is completely ignored and works completely different. What I am missing?


        Isomorphic:
        please don't waste your precious l337 h4x0r's time on such dummies like me. Thank you _very_ _much_ by pointing me to the doc, which I've read at the first, before even installing it. Next time just ignore any thread I've made here, OK? Thanks. :-*

        Comment


          #5
          shourisha, if your first post had not included a setColWidths() call with settings for two columns where you were clearly using 3, you would not have been directed to the docs. From what you posted it seemed clear that you had tried to copy an example rather than read the docs, which is common.

          Rather than more attitude, take the next clear step, which is to post your actual code.

          Comment


            #6
            A bit debugged cryptic output of GWT by Safari 4 debugger. So the thing never put any percentage, but re-calculates everything in pixels, each time you resize browser. And, of course, gets it wrong. Hence why my input field gets screwed, because "*" for SmartGWT means "1000 pixels" setting <cols> tags for table (sorry, I have really big monitor with a really huge resolution so did not really spot a difference between 700px and 1000px). If I clear that value to "100%", everything works as expected. Form also works great if I use something else then text input (label, for example), because I can set with of 100%. If I say: textItem.setWidth("100%"); — it is simply ignored.

            Thing shrinks to the simple question: how to set 100% width for a text item?..


            Isomorphic: Please, my darling... I've asked you politely once already: mea culpa is not worth your precious attention. :-*
            Last edited by shourisha; 28 May 2009, 19:16.

            Comment


              #7
              Widths are programmatically calculated in advance because you can't build a cross-browser stretchable layout like this in pure CSS (there is no concept of "fill remaining space" among other issues). Be sure you've set reasonable widths for the column with the title and the button (eg not "1"). Otherwise, those columns overflow, and the calculated width of the stretchable center column is now too large, pushing other controls offscreen.

              To avoid fixed sizes for columns containing labels, before rendering the form, measure the size of the label via rendering it in a Canvas offscreen, then take that size and use it as a column width.

              Comment


                #8
                Originally posted by Isomorphic
                there is no concept of "fill remaining space"
                I bet this would work everywhere (even in my terminal with ELinks, you know):

                Code:
                <table>
                  <tr>
                    <td width="0%" nowrap>I can be any width</td>
                    <td width="100%" nowrap>I take everything on a screen</td>
                    <td width="0%" nowrap>I am also dynamic here</td>
                  </tr>
                </table>
                I know what you're thinking about "nowrap" and "width=<percentage>", but I just showed you that there IS a concept of fill remaining space. And always been around, since plain old Mozaic times and first HTML born.

                So question still persists: How to set 100% width to com.smartgwt.client.widgets.form.fields.TextItem?

                P.S. Re-calculating widths myself? You serious about that? I even never doing this in Java Swing in my custom render widget!

                Comment


                  #9
                  Yes, that works, now try with form elements nested within that structure, remember that end user code can insert other custom elements, and see how far that goes :)

                  You already have a working solution - put reasonable sizes in your outer columns and the center column will stretch (just like Davidj6's SmartClient-based example).

                  Re: Swing: Swing has font metrics, we don't. The nearest equivalent is measuring specific text blobs offscreen, as suggested. This has a performance impact so it's not something the system does by default for a form for this specific use case; elsewhere, there are a number of autofit features.

                  Comment


                    #10
                    Originally posted by Isomorphic
                    You already have a working solution - put reasonable sizes in your outer columns and the center column will stretch (just like Davidj6's SmartClient-based example).
                    Isomorphic... :-) Look, I tried it already before posting but I wish it was working. Hence I am crying here, annoing everybody. OK, here are pictures to watch. You say is it normal behavior?.. I say it is just plain wrong for me, since title and button got fixed width in pixels, while text input got an asterisk (i.e. "*").

                    Moreover, there is a bug for sure: if I resize browser by a window corner, controls get nuts: width are plain wrong, controls are out of viewport etc. However, if I simply refresh the page, everything gets sorted out and width recalculated more/less correctly. This effect is seen in Safari 4 for Mac OS X.

                    Sorry for images are very bad quality due to plain stupid width limit of 620 pix. But I hope you will spot problems anyhow — see the huge gap between button and text input? "Picture 1" is what I want and what is working if I use something with 1200x800 screen resolution. However, "Picture 2" and "Picture 3" get nuts on bigger resolution. See the problems? I will help you: look at the gap in the title on the left side appeared, while I said setColWidth(200....). Why it grows when I asked to stick to 200px? Same with the button: see the gap at right side? It supposed to be also fixed width. When I resize 2000px width or more, why text input suddenly refuses to grow? I said "*" and doc says it suppose "to fill the rest of the space". Finally, I never said to Text Input "be no less that 100px width" — why it does not shinks even more to 60 or 40px, but sticks to 100px and generates me a horisontal scrollbar (not seen on a screenshot)?

                    P.S. Effect on "Picture 3" is probably because of entire JavaScript code is truly isomorphic: means polymorphes at runtime, mainly using random() function. :-P Joking, peace. :)
                    Attached Files
                    Last edited by shourisha; 28 May 2009, 22:29.

                    Comment


                      #11
                      Some more pictures, Iso, — you must love it, aren't you. :-) Effect is simple: maximize window of the browser, then drag-drag-drag-drag.... :-) Now, when I riched something like 650 px width of the browser, fun begins: forget that controls will get restored by themselves. They never will be (picture 5). However, after simple refresh everything FUBAR (picture 6).

                      Ideas? My idea: open your source editor and fix a bug in your awesome lib (insult on Java Swing that is on a main webpage I will remember very long time). But I might be wrong — maybe it is normal behavior?... :)
                      Attached Files

                      Comment


                        #12
                        Some more update.

                        Bad news
                        — Text input never gets wider than 1000 pix. I don't want even think than some l337 hardcoded stupid limits in JavaScript (sorry, no time to read that source code part).
                        — When browser gets resized from bigger to smaller, re-calculation of the widths works wrong and the only refresh is to rescue.
                        — When browser gets resized from smaller to bigger, re-calculation of the width works fine (very first issue still persists, however).

                        Good news
                        It is all cross-browser... :-)
                        Last edited by shourisha; 28 May 2009, 23:05.

                        Comment


                          #13
                          shourisha,
                          Stop being a smartass.

                          Regardless of whether you've found and issue or are having trouble getting started, such attitude will not be tolerated.

                          If you want help, or to participate in this forum, be professional and respectful. And if you want to be a smartass, you're not welcome here.

                          Please keep this in mind before responding or posing in the future.

                          Sanjiv

                          Comment


                            #14
                            Originally posted by sjivan
                            Regardless of whether you've found and issue or are having trouble getting started, such attitude will not be tolerated.
                            Sanjiv, got it. Not gonna be a smartass, sorry.

                            But my question still remains opened, regardless I am smartass or Isomorphic sent me to rtfm... :-( Maybe you know how to deal with that?

                            Comment


                              #15
                              That 1000px limit came from a recent regression, now fixed.

                              Not sure what "widths works wrong and the only refresh is to rescue." means but the test case posted by DavidJ6 works fine for shrinking or growing. Try emulating that and post your attempt if you think you've found a bug.

                              Comment

                              Working...
                              X