Expand And Collapse Miscelaneous Issues
Answered
Hi All,
Theres a couple of functionalities that arent really mixing well with expand and collapse. And often generate buggy or unexpected behaviour.
I understand most of the team's bandwith is focused on HTML5 modeler but I did want to bring these items up.
1) When using expand and collapse inserted rows are not pushed down or up.
Base situation:
Expected Result
Actual Result:
2) Formatting without cell attributes leads to rows inconsistently being formated. Here I've changed the background color from the "Egresos" (total expenses) line
When expanding any row above
The only way to solve this is with "Cell Attributes" and this is hard to maintain and error prone when you have several data types (for instances percentages and dollar amounts) in the same row.
3) The fact that enabling expand and collapse doesn't remove any sorting already present in the form generates inconsistent behaviour and the creation of an infinite number of rows.
Prerequisites to reproduce: Have sorting enabled on the form before enabling expand and collapse.
Before applying sort
After Sort
After enabling expand and collapse the + and minus signs are placed in the wrong members
Any number of duplicates are generated if you manage to expand a member. (a duplicate per click)
-
Official comment
Hi Santiago,
Thank you for writing in about all of these. Hopefully I can shed some clarity on the behaviors you're experiencing.
1) For inserting static rows, this is actually the intended behavior. This is because the blank row you're inserting exists on the same row number, no matter how the Form changes. To create a blank row that moves dynamically with the Form, we suggest creating a Header in the row / column definition of the Form.
2) When formatting Forms, formatting applied directly to the Form acts in the same way as the static row above-- the formatting exists on the row / column not the Dimension Members. So as the Form changes, it stays on the row / column it was applied to. You correctly identified that Cell Attributes are the way to resolve this, as Cell Attributes apply formatting based on the intersection of Dimension Members. This is the best practice solution for creating dynamic formatting that follows the Dimension Members as they move on the Form. You should only apply formatting directly to the Form if you expect the rows or columns to remain static (often the top row or left-most column tend to be static).
3) The last issue you've identified, I think is certainly a bug and we can repro on our end as well. We'll pass this along to the development team and see if we can get this addressed! Thank you very much for reporting this.
Let me know if you have any further questions,
Ian Britz
Comment actions
Please sign in to leave a comment.
Comments
1 comment