Customer: Blackrock
User: Blair Saunders
Case: 00608570
How do I expand the width of a column? The full name of “model_nm” is being cut off.
27 KB
294 KB
471 KB
294 KB
294 KB
294 KB
294 KB
1 KB
294 KB
853 B
296 KB
The Row Header columns are resizable in Table mode, but fixed to certain predefined widths in Chart mode. In this issue, we want to allow the user to resize the Row Header column in Chart mode. The UI should the same as in Table mode, which is by dragging the edge on the right hand side of the Row Header column.
Once the user has manually resized a Row Header column, the following are true:
<visualanalytics:#15499> Need to be able to expand the width of a column
Committed revision 56043
Changes required to persist the state of the hierarchy are pending and I am working on it.
<visualanalytics:#15499> Need to be able to expand the width of a column
Committed revision 56043
Changes required to persist the state of the hierarchy are pending and I am working on it.
Revision #56049
Following changes are completed.
QA can pick this story for testing. Please pick build #19.
Revision #56049
Following changes are completed.
QA can pick this story for testing. Please pick build #19.
Scenario 1
Scenario 2
Please list all unit tests that you have run to verify this issue and test thoroughly, as this feature in its current state seems to be very buggy.
Scenario 1
Scenario 2
Please list all unit tests that you have run to verify this issue and test thoroughly, as this feature in its current state seems to be very buggy.
Hi Nhi,
Thanks a lot for trying this out and revealing the issues to me. I think the placement of the sort icon very close to the column edge was responsible for the mix up of two actions. I have shifted it away just like in 'Table' mode to avoid that issue. Also, I have to repaint the BIChartPanel in order that Undo/Redo works properly.
For now, I have used the analytics sheet provided by you as well as the index.vizx sheet.
[Nhi]
Hi Hussain,
It seems to work much better with the latest checkin. However, I now notice the following problems. Please start each scenario by reopening the workbook as there seems to be some problems with states.
Scenario 3:
Scenario 4:
Scenario 5:
Scenario 6:
Scenario 7:
Hi Nhi,
Thanks a lot for trying this out and revealing the issues to me. I think the placement of the sort icon very close to the column edge was responsible for the mix up of two actions. I have shifted it away just like in 'Table' mode to avoid that issue. Also, I have to repaint the BIChartPanel in order that Undo/Redo works properly.
For now, I have used the analytics sheet provided by you as well as the index.vizx sheet.
[Nhi]
Hi Hussain,
It seems to work much better with the latest checkin. However, I now notice the following problems. Please start each scenario by reopening the workbook as there seems to be some problems with states.
Scenario 3:
Scenario 4:
Scenario 5:
Scenario 6:
Scenario 7:
A few more scenarios:
Scenario 1:
Scenario 2:
Scenario 3:
Scenario 4:
A few more scenarios:
Scenario 1:
Scenario 2:
Scenario 3:
Scenario 4:
Hi Nhi and Juhi,
Thanks for testing out the various scenarios. I have fixed the scenarios reported by you in Revision #56099
Only the last change related to the clearing of 'Manual Resizing' option in an already existing file is left, which I will push in the next commit.
Hi Nhi and Juhi,
Thanks for testing out the various scenarios. I have fixed the scenarios reported by you in Revision #56099
Only the last change related to the clearing of 'Manual Resizing' option in an already existing file is left, which I will push in the next commit.
More scenarios:
Scenario 1:
Scenario 2:
Scenario 3:
Scenario 4:
Scenario 5:
More scenarios:
Scenario 1:
Scenario 2:
Scenario 3:
Scenario 4:
Scenario 5:
Thanks to Nhi and Nisha for the detailed testing.
I have pushed the changes in commit #56111
Changes:
The changes should appear in build v19.5.0-dev-32
Regards
Hussain
Thanks to Nhi and Nisha for the detailed testing.
I have pushed the changes in commit #56111
Changes:
The changes should appear in build v19.5.0-dev-32
Regards
Hussain
HI Hussain
I found one issue
Scenario :
HI Hussain
I found one issue
Scenario :
Revision #56125
Handling a null pointer exception when a child key is null
Revision #56125
Handling a null pointer exception when a child key is null
The scenario found by Pankaj here is not fixed. Similarly, if you drag the resize guideline into the Rows deck, do NOT release mouse button, drag back into the chart canvas, then release the mouse button. Now move the mouse into the middle of a row header cell and it will become the resize cursor, which is incorrect.
Also, scenario 5 here is only partially fixed. In step 2 if you drag diagonally to the right/down before the tooltip appears, then the problem is reproduced.
The scenario found by Pankaj here is not fixed. Similarly, if you drag the resize guideline into the Rows deck, do NOT release mouse button, drag back into the chart canvas, then release the mouse button. Now move the mouse into the middle of a row header cell and it will become the resize cursor, which is incorrect.
Also, scenario 5 here is only partially fixed. In step 2 if you drag diagonally to the right/down before the tooltip appears, then the problem is reproduced.
Scenario 1:
Scenario 2:
Scenario 3:
Solution: Either fix the above 3 scenarios, or remove the ability to resize the width of the vertical axis, which ever is easier. Note that resizing of the width of the vertical axis is NOT a requirement.
Scenario 1:
Scenario 2:
Scenario 3:
Solution: Either fix the above 3 scenarios, or remove the ability to resize the width of the vertical axis, which ever is easier. Note that resizing of the width of the vertical axis is NOT a requirement.
Hi Nhi,
Thanks for suggesting the solution for this. However, implementing both axes height/width was akin to each other, just a few parametric changes were required and hence I decided to implement the same. I have pushed the changes along with solutions for your input scenarios of "Fit Chart" options in #13331. Please take the update of Revision # 56154.
Hi Nhi,
Thanks for suggesting the solution for this. However, implementing both axes height/width was akin to each other, just a few parametric changes were required and hence I decided to implement the same. I have pushed the changes along with solutions for your input scenarios of "Fit Chart" options in #13331. Please take the update of Revision # 56154.
QA - Please pick up build # 39 to test the same
QA - Please pick up build # 39 to test the same
Scenario 1:
Scenario 2:
Scenario 3
Scenario 4:
Scenario 1:
Scenario 2:
Scenario 3
Scenario 4:
QA, please verify the changes in build #41
QA, please verify the changes in build #41
Scenario 1:
Scenario 2:
Scenario 3:
Scenario 4:
Scenario 5:
Scenario 1:
Scenario 2:
Scenario 3:
Scenario 4:
Scenario 5:
Scenario 1:
Scenario 2:
Scenario 3:
Scenario 4:
Scenario 5:
Scenario 6:
Note that part of the fix for scenarios 4, 5, 6 should take the following approach: The "Swap nows and columns" action should implicitly perform the Worksheet > Clear > Manual Sizing first (which clears all manual sizing of header column width, axis size, and cell size), and then perform the actual swapping. The Undo should do the usual undo of swapping and restore all previous manual sizing that was being cleared.
Scenario 1:
Scenario 2:
Scenario 3:
Scenario 4:
Scenario 5:
Scenario 6:
Note that part of the fix for scenarios 4, 5, 6 should take the following approach: The "Swap nows and columns" action should implicitly perform the Worksheet > Clear > Manual Sizing first (which clears all manual sizing of header column width, axis size, and cell size), and then perform the actual swapping. The Undo should do the usual undo of swapping and restore all previous manual sizing that was being cleared.
Revision #56181
Revision #56181
Scenario 1:
Scenario 2:
Scenario 3:
Scenario 1:
Scenario 2:
Scenario 3:
Revision #56194
Fixed scenarios 2 and 3 mentioned in the above comment.
I am looking into scenario 1 where I think the precision loss is happening due to interconversion between float and integer datatypes.
Revision #56194
Fixed scenarios 2 and 3 mentioned in the above comment.
I am looking into scenario 1 where I think the precision loss is happening due to interconversion between float and integer datatypes.
Scenario 1:
Scenario 2:
java.lang.NullPointerException at com.aquafold.aquacore.open.chart.bi.BIChartPanel$BIChartMouseAdapter.mouseDragged(BIChartPanel.java:932) at java.awt.Component.processMouseMotionEvent(Component.java:6581) at javax.swing.JComponent.processMouseMotionEvent(JComponent.java:3342) at java.awt.Component.processEvent(Component.java:6302) at java.awt.Container.processEvent(Container.java:2238) at java.awt.Component.dispatchEventImpl(Component.java:4889) at java.awt.Container.dispatchEventImpl(Container.java:2296) at java.awt.Component.dispatchEvent(Component.java:4711) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4897) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4551) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4475) at java.awt.Container.dispatchEventImpl(Container.java:2282) at java.awt.Window.dispatchEventImpl(Window.java:2746) at java.awt.Component.dispatchEvent(Component.java:4711) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:760) at java.awt.EventQueue.access$500(EventQueue.java:97) at java.awt.EventQueue$3.run(EventQueue.java:709) at java.awt.EventQueue$3.run(EventQueue.java:703) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:90) at java.awt.EventQueue$4.run(EventQueue.java:733) at java.awt.EventQueue$4.run(EventQueue.java:731) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80) at java.awt.EventQueue.dispatchEvent(EventQueue.java:730) at com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.java:866) at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:650) at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:381) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
Scenario 1:
Scenario 2:
java.lang.NullPointerException at com.aquafold.aquacore.open.chart.bi.BIChartPanel$BIChartMouseAdapter.mouseDragged(BIChartPanel.java:932) at java.awt.Component.processMouseMotionEvent(Component.java:6581) at javax.swing.JComponent.processMouseMotionEvent(JComponent.java:3342) at java.awt.Component.processEvent(Component.java:6302) at java.awt.Container.processEvent(Container.java:2238) at java.awt.Component.dispatchEventImpl(Component.java:4889) at java.awt.Container.dispatchEventImpl(Container.java:2296) at java.awt.Component.dispatchEvent(Component.java:4711) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4897) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4551) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4475) at java.awt.Container.dispatchEventImpl(Container.java:2282) at java.awt.Window.dispatchEventImpl(Window.java:2746) at java.awt.Component.dispatchEvent(Component.java:4711) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:760) at java.awt.EventQueue.access$500(EventQueue.java:97) at java.awt.EventQueue$3.run(EventQueue.java:709) at java.awt.EventQueue$3.run(EventQueue.java:703) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:90) at java.awt.EventQueue$4.run(EventQueue.java:733) at java.awt.EventQueue$4.run(EventQueue.java:731) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80) at java.awt.EventQueue.dispatchEvent(EventQueue.java:730) at com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.java:866) at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:650) at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:381) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
Revision #56221
Changes:
Handling of the null pointer exception, depicted in scenario 2 in the above comment.
Changing the placement of the icon closer to the right edge of the cell.
Revision #56221
Changes:
Handling of the null pointer exception, depicted in scenario 2 in the above comment.
Changing the placement of the icon closer to the right edge of the cell.
Hi Nhi,
I checked the issue for the following scenario.
Scenario 1:
While resizing the size of the column, we fetch the width from the selected cell and use to restore to this width after performing an Undo operation, which in the case of the rowfield Header comes out to be '85'.
Though rendered cell width is actually calculated using BIChartRenderer::getFitCellWidth, which turns out to be '80'. Now, in this case, during a resizing of cell width, I only have selected cell's width available to me.
The only proper solution to this problem could be properly setting the value of the rowFieldHeader's cell width during preparing the workSheet. Right now, it is set through BIChartRenderer::getRowHeadersWidth, which causes it to differ from the fitCellWidth value.
I guess, undertaking this work for a cosmetic change would again increase the scope of the work. Please let me know your opinion about it.
Hi Nhi,
I checked the issue for the following scenario.
Scenario 1:
While resizing the size of the column, we fetch the width from the selected cell and use to restore to this width after performing an Undo operation, which in the case of the rowfield Header comes out to be '85'.
Though rendered cell width is actually calculated using BIChartRenderer::getFitCellWidth, which turns out to be '80'. Now, in this case, during a resizing of cell width, I only have selected cell's width available to me.
The only proper solution to this problem could be properly setting the value of the rowFieldHeader's cell width during preparing the workSheet. Right now, it is set through BIChartRenderer::getRowHeadersWidth, which causes it to differ from the fitCellWidth value.
I guess, undertaking this work for a cosmetic change would again increase the scope of the work. Please let me know your opinion about it.
Revision #56222
In case a Clear -> Manual Sizing is invoked while "Table" mode is active, ChartManualSizingInfo would not be available since ChartModel is not ready yet. Hence, we need to supply the default null values to it for various Chart related fields like RowHeaderHierarchy's width, Preferred Cell Width, Preferred Row Height etc.
Revision #56222
In case a Clear -> Manual Sizing is invoked while "Table" mode is active, ChartManualSizingInfo would not be available since ChartModel is not ready yet. Hence, we need to supply the default null values to it for various Chart related fields like RowHeaderHierarchy's width, Preferred Cell Width, Preferred Row Height etc.
Code Review:
The approach for the storage and persistence of the row header column width is incorrect. This approach uses the BIChartConfigAPI._nodeHeightWidthAttributes and PivotHeaderNode.width to store the row header column width. Because of the incorrect approach, the following scenario fails:
The mechanism for the storage and persistence of the row header column width already exists in Table mode, and the same mechanism should also be re-used in Chart mode. Basically the storage is in BIModelField._properties._columnWidth. If _columnWidth is NULL, it means that the column width is not manually sized. If it's not NULL, then its value should be used as the width of the corresponding row header column. By re-using the same mechanism, you can also leverage the undo logic for saving the state of the manual sizing.
I have attached 15499-prototype.patch, which is a simple prototype (which is NOT a complete solution) of re-using this mechanism for Chart mode. After you apply the patch, the resize action in Chart mode will no longer work because the prototype uses the table mode storage mechanism for row header column width. However you can see its effect by resizing the row header column width in Table mode first, then change chart type to Bar chart. You'll see that the row header width is retained. We could change the logic to first clear all manual sizing when changing chart type.
Please reach out to me if you have any questions regarding this. Perhaps we can talk tomorrow morning at 8:00 am pacific time.
Code Review:
The approach for the storage and persistence of the row header column width is incorrect. This approach uses the BIChartConfigAPI._nodeHeightWidthAttributes and PivotHeaderNode.width to store the row header column width. Because of the incorrect approach, the following scenario fails:
The mechanism for the storage and persistence of the row header column width already exists in Table mode, and the same mechanism should also be re-used in Chart mode. Basically the storage is in BIModelField._properties._columnWidth. If _columnWidth is NULL, it means that the column width is not manually sized. If it's not NULL, then its value should be used as the width of the corresponding row header column. By re-using the same mechanism, you can also leverage the undo logic for saving the state of the manual sizing.
I have attached 15499-prototype.patch, which is a simple prototype (which is NOT a complete solution) of re-using this mechanism for Chart mode. After you apply the patch, the resize action in Chart mode will no longer work because the prototype uses the table mode storage mechanism for row header column width. However you can see its effect by resizing the row header column width in Table mode first, then change chart type to Bar chart. You'll see that the row header width is retained. We could change the logic to first clear all manual sizing when changing chart type.
Please reach out to me if you have any questions regarding this. Perhaps we can talk tomorrow morning at 8:00 am pacific time.
Hi Nhi,
I completely agree with your observation and hence I am changing the persistence mechanism. Now, I am using two new fields in BIProperties and BIFieldPropertiesData to store preferredChartNodeWidth and preferredChartNodeHeight. From now, BIChartConfigAPI._nodeHeightWidthAttributes would act merely as a transient field so that we can handle the cases of Manual resizing during "Clear Manual resize" and "Swap of Rows/Columns".
Though I didn't took your patch and worked with it, yet I completely grasped the problem. However, I differ in opinion to reuse the table stuff in chart mode because in case we do so, we have to rework a lot of things and next we have to also "Clear the Manual sizing" of the chart before switching to the table mode.
Right now, after resizing the rows/columns in "Table" mode once we switch to the "Charts" and switch back to "Table" mode the manual sizing persists. In case, we leverage the existing fields used by the "Table" we may have to clear the fields while switching to and fro from the "chart mode" and reinstating fields from "Table" mode would entail further work. Hence, I think storing them in separate fields is better. Please let me know your opinion over it.
With Revision #56231, the scenario mentioned by you is fixed.
Thanks - Hussain
Hi Nhi,
I completely agree with your observation and hence I am changing the persistence mechanism. Now, I am using two new fields in BIProperties and BIFieldPropertiesData to store preferredChartNodeWidth and preferredChartNodeHeight. From now, BIChartConfigAPI._nodeHeightWidthAttributes would act merely as a transient field so that we can handle the cases of Manual resizing during "Clear Manual resize" and "Swap of Rows/Columns".
Though I didn't took your patch and worked with it, yet I completely grasped the problem. However, I differ in opinion to reuse the table stuff in chart mode because in case we do so, we have to rework a lot of things and next we have to also "Clear the Manual sizing" of the chart before switching to the table mode.
Right now, after resizing the rows/columns in "Table" mode once we switch to the "Charts" and switch back to "Table" mode the manual sizing persists. In case, we leverage the existing fields used by the "Table" we may have to clear the fields while switching to and fro from the "chart mode" and reinstating fields from "Table" mode would entail further work. Hence, I think storing them in separate fields is better. Please let me know your opinion over it.
With Revision #56231, the scenario mentioned by you is fixed.
Thanks - Hussain
There is imprecision when resizing row header width and the undoing of it. Consider the following scenario:
This is because the row column width calculation later will add BIChartRenderer.INDENT to the size to accommodate some margins for the row header cells. Thus you must account for this.
I've attached 15499-fix-wrong-size.patch which address this. Please take a look and apply the patch with you don't see any problems with it.
---------------------------------------------------
Scenario 1:
Scenario 2:
java.lang.NullPointerException at com.aquafold.bistudio.model.BIChartConfigAPI.createNodeTree(BIChartConfigAPI.java:699) at com.aquafold.bistudio.model.BIChartConfigAPI.buildRowTree(BIChartConfigAPI.java:585) at com.aquafold.bistudio.model.BIChartConfigAPI.reconfigure(BIChartConfigAPI.java:534) at com.aquafold.bistudio.model.BIModel.calculateModelImpl(BIModel.java:1223) at com.aquafold.bistudio.model.BIModel.access$200(BIModel.java:166) at com.aquafold.bistudio.model.BIModel$2.process(BIModel.java:863) at com.aquafold.bistudio.component.BISimpleProgressDialog.run(BISimpleProgressDialog.java:96)
There is imprecision when resizing row header width and the undoing of it. Consider the following scenario:
This is because the row column width calculation later will add BIChartRenderer.INDENT to the size to accommodate some margins for the row header cells. Thus you must account for this.
I've attached 15499-fix-wrong-size.patch which address this. Please take a look and apply the patch with you don't see any problems with it.
---------------------------------------------------
Scenario 1:
Scenario 2:
java.lang.NullPointerException at com.aquafold.bistudio.model.BIChartConfigAPI.createNodeTree(BIChartConfigAPI.java:699) at com.aquafold.bistudio.model.BIChartConfigAPI.buildRowTree(BIChartConfigAPI.java:585) at com.aquafold.bistudio.model.BIChartConfigAPI.reconfigure(BIChartConfigAPI.java:534) at com.aquafold.bistudio.model.BIModel.calculateModelImpl(BIModel.java:1223) at com.aquafold.bistudio.model.BIModel.access$200(BIModel.java:166) at com.aquafold.bistudio.model.BIModel$2.process(BIModel.java:863) at com.aquafold.bistudio.component.BISimpleProgressDialog.run(BISimpleProgressDialog.java:96)
#Revision 56238
Changes:
#Revision 56238
Changes:
Revision #56240
Fixing a bug where in manual clearing of sizes (do, undo, redo) were not reflecting properly for the RowHeaderTable in charts.
Revision #56240
Fixing a bug where in manual clearing of sizes (do, undo, redo) were not reflecting properly for the RowHeaderTable in charts.
The following scenario is still observed:
The following scenario is still observed:
The Chart Fit dropdown itself is the root cause of the scenario in the previous comment. The problem can be reproduced in a much more basic scenario as follows:
Basically any operation that cause the chart to get updated will change the Chart Fit option back to Standard. This defect is a violation of requirement #7 in the Add manual cell sizing support issue #13331. Thus this defect must be fixed. You may change the implementation of this dropdown component if necessary.
The Chart Fit dropdown itself is the root cause of the scenario in the previous comment. The problem can be reproduced in a much more basic scenario as follows:
Basically any operation that cause the chart to get updated will change the Chart Fit option back to Standard. This defect is a violation of requirement #7 in the Add manual cell sizing support issue #13331. Thus this defect must be fixed. You may change the implementation of this dropdown component if necessary.
Hi Nhi,
I am reverting the changes mentioned in the above with revision # 56258
Unfortunately, the above approach brings in more issues than solved. The problem with the ChartFitUI component is that it is invoked from BIToolBar::handleWorksheetTabChanges which makes it difficult to be explicitly controlled from any of our operations. To be precise the value set from the getSelectedValue() of this component is is directly derived from the four combinations arising out of the configAPI::isFitWidth and configAPI::isFitHeight.
Owing to this nature of setting the value in the combo box, it is never directly set by any of the operations -> Transpose of the rows & columns, Change of the chartFitment through combo box (again handled through handler to read the selected value). It is always done implicitly. It is only in Chart Resize that in order to meet the condition of setting the value of manual resize that we need to set the selected value to NULL.
Now after an undo/redo operation in case I am trying to set the value it succeeds first. But the value is reset later as event handling in the BIToolBar::handleWorkSheetTabChanges causes it is again to reset to the value on the basis of these two flags configAPI::isFitWidth and configAPI::isFitHeight.
If possible let me know in case we can discuss this today your morning.
[Nhi] Let's follow the Table mode approach.
Hi Nhi,
I am reverting the changes mentioned in the above with revision # 56258
Unfortunately, the above approach brings in more issues than solved. The problem with the ChartFitUI component is that it is invoked from BIToolBar::handleWorksheetTabChanges which makes it difficult to be explicitly controlled from any of our operations. To be precise the value set from the getSelectedValue() of this component is is directly derived from the four combinations arising out of the configAPI::isFitWidth and configAPI::isFitHeight.
Owing to this nature of setting the value in the combo box, it is never directly set by any of the operations -> Transpose of the rows & columns, Change of the chartFitment through combo box (again handled through handler to read the selected value). It is always done implicitly. It is only in Chart Resize that in order to meet the condition of setting the value of manual resize that we need to set the selected value to NULL.
Now after an undo/redo operation in case I am trying to set the value it succeeds first. But the value is reset later as event handling in the BIToolBar::handleWorkSheetTabChanges causes it is again to reset to the value on the basis of these two flags configAPI::isFitWidth and configAPI::isFitHeight.
If possible let me know in case we can discuss this today your morning.
[Nhi] Let's follow the Table mode approach.
All Undo operations of Manual Clear Resizing, Swap of Rows/Columns and Manual changing of ChartFit UI option which affect the fitment should revert the state of the chart to the previous manually resized state.
In this way, we are able to achieve similarity alike Table mode.
QA. Please test the scenarios.
All Undo operations of Manual Clear Resizing, Swap of Rows/Columns and Manual changing of ChartFit UI option which affect the fitment should revert the state of the chart to the previous manually resized state.
In this way, we are able to achieve similarity alike Table mode.
QA. Please test the scenarios.
Revision # 56260
On selection of Fit-Width/Fit-Height options from ChartUI combo-box the corresponding scroll bars should not appear.
Thanks to Priyanka for figuring out the corner scenario.
Revision # 56260
On selection of Fit-Width/Fit-Height options from ChartUI combo-box the corresponding scroll bars should not appear.
Thanks to Priyanka for figuring out the corner scenario.
Scenario 1:
Scenario 2:
Scenario 1:
Scenario 2:
Scenario 1:
Scenario 2:
Scenario 3:
Code Review:
Scenario 1:
Scenario 2:
Scenario 3:
Code Review:
Revision #56268
Changes:
Scenario 3 is going to take a significantly lot of time because we have to update the existing mechanism for drawTextInCell. Here the computation has to take many factors into account.
Before writing the text in the cell the textWidth is computed via the bounds of a Rectangle2D through textRenderer.getBounds(text). This is finally used to compute the minimum cell width which is required to draw the text in the cell. This is significantly different from Table Mode because there we don't have such level of sophistication. I guess it would be better than we do not undertake this change for now.
Revision #56268
Changes:
Scenario 3 is going to take a significantly lot of time because we have to update the existing mechanism for drawTextInCell. Here the computation has to take many factors into account.
Before writing the text in the cell the textWidth is computed via the bounds of a Rectangle2D through textRenderer.getBounds(text). This is finally used to compute the minimum cell width which is required to draw the text in the cell. This is significantly different from Table Mode because there we don't have such level of sophistication. I guess it would be better than we do not undertake this change for now.
Hi,
All the above scenarios are working fine as per the expectations on ADS19.5.0-dev-61 build. Hence marking it as Verified.
Hi,
All the above scenarios are working fine as per the expectations on ADS19.5.0-dev-61 build. Hence marking it as Verified.
Scenario 1:
Scenario 1:
Revision #56275
Changes: Applying custom preferences after ChartFit Undo/Redo operation is no longer required since we are in coherence with table mode.
Revision #56275
Changes: Applying custom preferences after ChartFit Undo/Redo operation is no longer required since we are in coherence with table mode.
Scenario 1:
Scenario 2:
Scenario 1:
Scenario 2:
Hi Nhi,
I fixed both scenarios mentioned above. Please have a look.
The FitHeight and FitWidth is working as expected and also Entire View is working fine along with undo redo operations.
Hi Nhi,
I fixed both scenarios mentioned above. Please have a look.
The FitHeight and FitWidth is working as expected and also Entire View is working fine along with undo redo operations.
Scenario 1:
Scenario 2:
Scenario 1:
Scenario 2:
Looks good.
@QA: Please retest all past scenarios.
Looks good.
@QA: Please retest all past scenarios.
Hi,
All the above scenarios are working fine as per the expectations on ADS19.5.0-dev-65 build. Hence marking it as Verified.
Hi,
All the above scenarios are working fine as per the expectations on ADS19.5.0-dev-65 build. Hence marking it as Verified.
Reopen for the following breakage:
This breakage is caused by BIChartPanel::getManualSizingInfo(). The breakage scenario is constructed by first setting Chart Type to Table on an empty worksheet before adding any fields to Rows and Columns decks.
Reopen for the following breakage:
This breakage is caused by BIChartPanel::getManualSizingInfo(). The breakage scenario is constructed by first setting Chart Type to Table on an empty worksheet before adding any fields to Rows and Columns decks.
Fixed null pointer exception mentioned in above comment. These changes are part of below mentioned revision no.:
Fixed null pointer exception mentioned in above comment. These changes are part of below mentioned revision no.:
Issue #15499 |
Resolved |
Fixed |
Resolved |
Completion |
No due date |
Fixed Build ADS19.5.0-dev-69 |
No time estimate |
1 issue link |
relates to #13331
Issue #13331Add manual cell sizing support |
The Row Header columns are resizable in Table mode, but fixed to certain predefined widths in Chart mode. In this issue, we want to allow the user to resize the Row Header column in Chart mode. The UI should the same as in Table mode, which is by dragging the edge on the right hand side of the Row Header column.
Once the user has manually resized a Row Header column, the following are true: