3E Layout behaves like two 2E layouts

Suite and Optimus Suite 5
#1

While trying to upgrade my team’s application from DHTMLX 3.6 to 4.0.2, I noticed that the 3E layout pattern is not behaving as it used to. While its initial appearance is correct, it does not appear possible to collapse both cells ‘b’ and ‘c’ at the same time; if I collapse one, the other expands, regardless of the fact that cell ‘a’ is still expanded.

When trying to figure out what was going on, I noticed that the structure of the HTML DIVs indicates that DHTMLX is not generating a 3E layout as requested. See the attached screenshot, which is a snippet from Google Chrome’s Developer Tools. Each div with a “dhx_cell_layout” class represents a cell in a layout; the notations in black text I’ve added on the left indicate which div maps to which cell in the layout shown on-screen. What I should see - what I saw in 3.6 - is a layout like this:

  • Root - 2U Layout
    [list]
    [*]a - Component
  • b - 3E Layout
    [list]
    [*]a - Component
  • b - Component
  • c - Component
    [/:m][/list:u][/:m][/list:u]

What I’m actually seeing, as indicated in the screenshot, is this:

  • Root - 2U Layout
    [list]
    [*]a - Component
  • b - 2E Layout
    [list]
    [*]a - Component
  • b - 2E Layout
    [list]
    [*]a (called b) - Component
  • b (called c) - Component
    [/:m][/list:u][/:m][/list:u][/*:m][/list:u]

The requirements for our application state that we need to be able to collapse both cells b and c in the 3E layout. I don’t see how this is possible if a 3E layout is generated in this manner. Does anyone have any tips on how to avoid this?

3E Layout Structure.png1000×197 28.2 KB

#2

It looks as though the 3W layout is doing the same thing; it’s being implemented as a 2U layout which contains another 2U layout in cell B.

#3

Hello

that’s right. we modified layout inner logic a bit, so now actually it can be only 2E, 2U or 1C. all other patterns are just combinations of listed above.

pleade try attached modified 3E

dhtmlXLayoutObject.prototype.tplData[“3E”] = {mode:“h”,cells:{a:{height:2/3,layout:{mode:“h”,cells:{a:{name:“a”,fsize:{v:1}},b:{name:“b”,fsize:{v:[1,2]}}}}},b:{name:“c”,fsize:{v:2}}}};

#4

Thanks - that works well enough for this particular case, and I think I see how I can modify that to fix quirks with other layouts we’re using. Regardless, though, this doesn’t seem to match up with your documentation’s description of how cells expand and collapse. It says:

So in large layouts like 5W, this mostly holds true; I can collapse cells a, b, and c all at once, or in any combination… but even if all of cells a, b, and c are expanded, I can only ever collapse one of cells d and e at a time, but not both; since they’re both held within the same inner 2U layout, one of them must remain expanded at all times. I’d urge you to reconsider this change, or at least modify your documentation so that people know what to expect from this.

#5

The code snippet you provided is actually causing another problem…

In another place in our application, we’re using a 3W layout that contains a 3E layout in each of its cells. Before I added the snippet, each of the 3W cells was showing its header and could be collapsed and expanded. Afterward, however, the headers for these cells are not being displayed, no matter what I do (calling .showHeader() doesn’t have any effect). As a result, I’m now unable to collapse these cells.

#6

Hi

please open ticket in support system and attach completed demo

#7

I don’t have direct access to our team’s support login, but I can try to get something put together. I’m currently in the process of modifying the layout component itself in order to allow layouts with more than two cells to be created; that takes priority for us right now.

#8

well, then you can take layout 3.6 base and 4.0 container part

#9

I’ll give that a shot, thanks. I hope to have that demo ready soon as well.

#10

Using the 3.6 layout file isn’t working - when the page loads I get an alert message saying “dhtmlxcontainer.js is missed on the page”, followed by a large number of javascript errors. This is what I have in my header:

[code]

[/code]

Switching the order of the last two imports has no effect.

That said, I’ve been working on those demos you asked for and for some reason I’m not seeing the problem with your modified layout that I was seeing in our application. I’m not sure what the difference is, but I’ll try to investigate that now.

#11

Ok, I think I’ve got the problem figured out. I apologize, I left out some details of my team’s layout before as I didn’t think they were relevant, but it turns out they are. My team’s full layout looks something like this:

  • Root level - 2U layout
    [list]
    [*]Cell A - Components

  • Cell B - Scrolling DIVs, which contain a 3W layout
    [list]
    []Cell A - 3E layout
    [list]
    [    ]Cell A - Components

  • Cell B - 1C Layout
    [list]
    []Cell A - Components
    [/    :m]
    []Cell C - Components[/:m][/list:u][/:m]
    [    ]Cell B - 3E layout

  • Cell A - Components

  • Cell B - 1C Layout
    [list]
    []Cell A - Components
    [/    :m]
    []Cell C - Components[/:m][/list:u][/:m]
    [    ]Cell C - 3E layout

  • Cell A - Components

  • Cell B - 1C Layout
    [list]
    []Cell A - Components
    [/    :m]
    []Cell C - Components[/:m][/list:u][/:m][/list:u][/:m][/list:u][/*:m][/list:u]

In version 3.6, as I mentioned above, we were able to collapse each of the cells of the 3W layout, and collapsing cells regardless of layout worked as described (that is, collapsed cells remained collapsed unless you were collapsing the only remaining expanded cell in a row/column; then one other cell would expand).

When we upgraded to 4.0, the collapsing behavior changed, such that only one of the last two cells in a row/column could be collapsed at a time, regardless of the state of other cells in the same row/column. The code snippet you provided doesn’t completely fix that issue, but it works well enough for our 3E layouts since we prevent the user from being able to collapse the top-most cell.

However, your code snippet revealed another issue, which I previously thought was caused by the code snippet itself. When the snippet was added, the cell headers for the 3W layout’s cells disappeared, preventing the user from being able to collapse those cells. Calling showHeader() on those cells had no effect either. However, when you asked me to put together a demo showing this problem, this problem did not occur; I’d set up simply a 3W containing a bunch of 3E’s, as I’d thought that was all that was relevant. I then decided that to fully demonstrate this, I needed to set up the demo to mimic our application as closely as possible. I added the 2U layout and the scrolling DIVs, and the problem still wasn’t present. Once I added the 1C layouts, then the headers disappeared. It seems that the addition of another layer of layouts and your code snippet is what is necessary to make this problem appear.

Anyway, as I mentioned above, I don’t have access to our team’s support login information (the suite was purchased through a procurement officer and it’s too much of a pain to hunt the information down), so I’ve uploaded the demos here. Don’t worry, I switched the code over to the standard version before uploading so that the professional version of the code is not exposed. There are four demos contained within the attached zip file which together demonstrate each of the problems I’ve described.

For now, it seems as though the quickest and easiest solution is to just remove the 1C layouts. I’m not quite sure why they were added in the first place, and clearly their presence is just causing problems now. We’ll just have to deal with the collapsing behavior for now, but a fix for that would be appreciated.

Thanks for your time and sorry for causing such a confusing mess.
LayoutBugDemo.zip (291 KB)

#12

Hi

not exactly this way.

I mean take source code of 3.6, find part where 3.6 container used abd replace it with 4.0 (common init, unload, remove 3.6 functionality)

also you will need to update some css container’s classes (remove 3.6, modify prefix for 4.0)

something like.

#13

regarding last your post - please attach 3.6 correctly working demo just to compare

#14

I only have access to the professional version of 3.6; we didn’t download the standard version before it became unavailable.

#15

not a problem, just send your demo to support@dhtmlx.com

#16

Sent!