Announcement

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

    Layout responsiveness to browser resize action

    Hi guys! I have a layout design similar to the Showcase: a tree on the left with a split and a main panel on the right. But the difference is that I do not want to show the selected panel in a TabSet. More exactly on the right of the split I have a VLayout as main panel. Each time I select something in the tree, I add the new panel as a member to the main panel, hide the previous selected panel and show the new one. Everything is fine until I resize the browser. Scrollbar appear instead of resizing the current visible panel. It seems that the size of the other members of the main panel is taken into consideration although they are not visible and that is why the scroll appears...

    According to a similar thread "a canvas with its visibility set to "hidden" still contributes to the scroll-size of its parent (this is related to native browser behavior with CSS). Layouts have some special logic to ignore the size of hidden members which doesn't exist for simple parent canvases." And I am using a VLayout not a Canvas as main panel but the scroll still appears...

    Adding/removing members on selection is a no go solution because it takes longer to draw and it looses all graphical details (scroll position etc.). Hence show/hide is a better approach. But how can I avoid the scroll behavior on browser resize?

    #2
    With your right-hand pane, you may be reinventing the Deck component, which automatically manages a set of panes, keeping only visible at a time (like a TabSet with no tabs).

    In browsers/HTML in general, yes, hidden elements still contribute to scroll area. You can either move them offscreen (negative coordinates), set hideUsingDisplayNone, or clear() then when hiding.

    Comment


      #3
      Brilliant answer!! It seems I was reinventing the wheel... The hideUsingDisplayNone is also useful for the case of showing a "Loading..." message in a modal Window until the interface is created.
      Last edited by slick07; 23 Jul 2020, 03:59.

      Comment


        #4
        Since I started using the hideUsingDisplayNone() method I see this type of warnings in the console: "row heights not yet available; returning all zeroes" for a TreeGrid. They appear when the Canvas that contains the grid is hidden and the grid has these settings:
        Code:
        setShowRecordComponents(true);
        setShowRecordComponentsByCell(true);
        or these ones:
        Code:
        setShowRollOver(true);
        setShowRollOverCanvas(true);
        setShowRollUnderCanvas(false);
        setUseCellRollOvers(true);
        If I comment the above settings the warnings disappear. I assume that by adjusting the data source in another visible canvas it triggers certain events to the TreeGrid (that is hidden and shares the same data source). But I do not know why they appear because I am not interrogating the row height... hence is it a bug or am I doing something wrong?

        Comment


          #5
          When using hideUsingDisplayNone, the browser will not give us any valid sizes for content we render (because it is skipping the work of rendering the HTML). This is harmless, since the TreeGrid already handles this by just getting the needed sizes once the component is shown, but it is potentially a reason to use Deck or the other approaches we mentioned above - as doc'd, hideUsingDisplayNone has native issues, and its use is only semi-supported.

          Comment


            #6
            The first time I tried to use Deck but it seemed that it does not solve the problem. I still needed to use the hideUsingDisplayNone() for each component of the Deck hence I dropped this solution. I could try again but I think the result will be the same... Is there a sample case for Deck in the showcase? I was not able to find one...

            Comment


              #7
              No, there's no sample, it's a bit too trivial.

              Deck is a Layout subclass, so you should find it ignoring hidden content; if you don't, you could submit a test case showing the problem.

              Note also that beyond Deck we offered yet more approaches, including moving offscreen, which also avoid the problem without using display:none, which is documented as triggering various native browser issues, including the one you've run across, where browsers report bogus numbers for sizes of display:none content.

              Comment


                #8
                Hmm... so what would be the equivalent on/off screen code for the show/hide methods?

                Comment


                  #9
                  moveTo(0, -10000)

                  Comment

                  Working...
                  X