Announcement

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

    AutoFitTextAreaItem doesn't allow vertical scrollbar even with maxHeight set

    Be sure your post includes:
    1. smartgwt 4.0pNov07
    2. Firefox 24.8.1

    Question:
    I am trying to make an AutoFitTextAreaItem with maxHeight set, but I also want a vertical scrollbar in case someone puts in lots of text. The problem is that it always sets overflow: hidden, so excess text just disappears.

    I used FireBug to edit the style in the browser and after some experimentation, what I want is to add in overflow-y: scroll and remove overflow: hidden from the style. This solves the problem (in Firefox 24 dev mode at least). Unfortunately, I can't find a way to modify the styles the way I want using any of the FormItem/TextAreaItem/AutoFitTextAreaItem methods.

    This is going in to a DynamicForm, so I want the solution to be a subclass of Formitem.

    It seems bizarre that TextAreaItem has scrollbars but direct subclass AutoFitTextAreaItem doesn't get them back when you call setMaxHeight(). I understand why AutoFitTextAreaItem doesn't have scrollbars normally, but they should reappear when you limit the height of the box.

    #2
    The maxHeight attribute isn't supported on AutoFitTextAreaItem, partly because the DOM settings you found only work in some browsers in some cases.

    Comment


      #3
      If it's not supported, then why is there a setMaxHeight() method in AutoFitTextAreaItem that does precisely that?

      http://www.smartclient.com/smartgwt/javadoc/com/smartgwt/client/widgets/form/fields/AutoFitTextAreaItem.html#setMaxHeight(java.lang.Integer)

      Comment


        #4
        Can you clarify the behavior you see and the behavior you're looking for?

        You seem to be saying that the textArea reaches the max height, doesn't grow large, but no scrollbars appear? That's not the case in our testing, although note we're testing 4.1 - there's no reason to be doing new development on 4.0 now, which is two versions behind.

        Another possibility - you might have external CSS affecting the behavior of all textAreas (see FAQ).

        Comment


          #5
          I don't think there's any external CSS involved here.

          Anyway, here is more detail, sorry for the confusion:

          1) Scenario 1
          FormItem is a TextAreaItem in a DynamicForm that spans the entire form horizontally. setHeight has been called upon this TextAreaItem, such that after about 5-6 lines of text have been entered, you must scroll to see it all, which is problematic at times.

          2) Scenario 2
          FormItem is an AutoFitTextAreaItem in the same form as above. When you add text to it, it expands vertically to accomodate the amount of text in the text area. The problem here is that if the user enters a large number of small paragraphs, the text can end up stretching the text area very far, vertically. It would be better to have some sort of upper bound on the size it can grow.

          3) Scenario 3
          FormItem is again an AutoFitTextAreaItem but this time setMaxHeight() has been called so that it can't grow beyond an arbitrary number of pixels in vertical height. As a result, the box grows vertically to fit added text until it reaches this height. The problem is that once this limit is reached, all the extra text disappears from the visible area and no scrollbars are provided to reach it. You must click in the field and use the arrow keys to move the cursor into the hidden text.

          4) Actual desired behavior:
          FormItem is an AutoFitTextAreaItem with an upper bound for vertical size, but a vertical scrollbar is provided for situations where that upper bound is exceeded.

          Comment


            #6
            Any word on this? It seems like it should be a trivial problem to fix.

            Comment


              #7
              So to clarify, the behavior is as documented, but you would like a scrollbar added.

              We don't plan to add one at this time. It's not at all a trivial problem to fix (at the intersection of size detection and scrolling is where browsers have horrible thickets of interlocking bugs). It's also not better for all circumstances - a scrollbar burns space, and the fact that a autoFit and maxHeight settings are being used strongly implies the value is typically short, therefore easy enough to manage with keyboard navigation (and scroll wheel, or swipe on mobile / trackpads).

              If you feel this is really important for your application, you can use the Feature Sponsorship program to have a property added to control whether a scrollbar is shown.

              Comment

              Working...
              X