The EditableListOption class is having issues with java 1.8. If this class is been used it seems that if you hit enter the value gets passed and set but if you lose focus on the object in any other way, such as tab or moving the mouse somewhere else and clicking focus the value is lost and blank is passed down. You can break point on AnOption SetValue Method.
@asif: as an example, launch the create table UI for SQL Server. Add a field & then click on the "Default Value" section in the bottom of the screen. Type in a value & press the tab key instead of the enter key. You'll notice that your value is not persisted. To persist the value, user has to press the enter key. If we run ADS v17 w/ the 1.7 jre, this problem does not exist. You are able to use either the tab or the enter key & the value persists.
I recall for Import, that we had similar issues w/ the pressing the tab key & the value not persisting. But import doesn't use EditableListOption. However, possibly whatever you did to fix the import scenario could also be applied here?
Also note that I tried running ADS v17 w/ the 1.8.0_72 jre. The tab problem still exists.
From past experience, the problem has to do with CComboBox in a Table Cell as an editor. Historically, we have had similar problems related to Java. So, the problem isn't specifically to EditableListOption, but with ListOption->ListCellEditor->CComboBox or any CComboBox in a Table Cell editor. So, if the Import uses a CComboBox in a table cell editor then it could be related.
Note that the problem usually occurs in the Cell Editors .stopCellEditing() method. ListCellEditor overrides the default .stopCellEditing() method and reference issue #1331. So, this may be related.
From past experience, the problem has to do with CComboBox in a Table Cell as an editor. Historically, we have had similar problems related to Java. So, the problem isn't specifically to EditableListOption, but with ListOption->ListCellEditor->CComboBox or any CComboBox in a Table Cell editor. So, if the Import uses a CComboBox in a table cell editor then it could be related.
Note that the problem usually occurs in the Cell Editors .stopCellEditing() method. ListCellEditor overrides the default .stopCellEditing() method and reference issue #1331. So, this may be related.
Interim Update: I can reproduce this issue on Windows 8 and OSX. On OSX, I can replicate the issue using a normal JTable with an editable JComboBox as well.
Note that on Ubuntu Linux, the value is saved as expected on TAB key.
Looks like the solution is to customize the TableCellEditor and provide the correct cell editor value; something like this
@Override public Object getCellEditorValue() { return comboBox.getEditor().getItem(); }
Interim Update: I can reproduce this issue on Windows 8 and OSX. On OSX, I can replicate the issue using a normal JTable with an editable JComboBox as well.
Note that on Ubuntu Linux, the value is saved as expected on TAB key.
Looks like the solution is to customize the TableCellEditor and provide the correct cell editor value; something like this
@Override public Object getCellEditorValue() { return comboBox.getEditor().getItem(); }
The problem that we're experiencing seems to be described in this JRE issue:
https://bugs.openjdk.java.net/browse/JDK-8068047
A fix is targeted for jre 1.9.
The problem that we're experiencing seems to be described in this JRE issue:
https://bugs.openjdk.java.net/browse/JDK-8068047
A fix is targeted for jre 1.9.
Here is another related JRE issue:
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8072767
And we are using the recommended workaround for the above issue as a fix. This solves TAB key not saving edited value issue on Windows and OSX.
new CComboBox() { @Override public void actionPerformed(ActionEvent e) { Object source = e.getSource(); if (source instanceof DefaultCellEditor) { e = new ActionEvent(getEditor(), e.getID(), e.getActionCommand()); } super.actionPerformed(e); } }
Here is another related JRE issue:
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8072767
And we are using the recommended workaround for the above issue as a fix. This solves TAB key not saving edited value issue on Windows and OSX.
new CComboBox() { @Override public void actionPerformed(ActionEvent e) { Object source = e.getSource(); if (source instanceof DefaultCellEditor) { e = new ActionEvent(getEditor(), e.getID(), e.getActionCommand()); } super.actionPerformed(e); } }
Fix is available in US v17 branch and US Trunk.
Fix is available in US v17 branch and US Trunk.
verified working in ads-windows-xxx-17.0.2-9.xxx installers...
verified working in ads-windows-xxx-17.0.2-9.xxx installers...
Verified in ADS v17.0.3 for OSX which was the Customers environment. Will do more testing.
Verified in ADS v17.0.3 for OSX which was the Customers environment. Will do more testing.
Issue #14270 |
Closed |
Fixed |
Resolved |
Completion |
No due date |
Fixed Build ADS 17.0.2-9, ADS 18.0.0-dev-49 |
No time estimate |
1 issue link |
relates to #1331
Issue #1331DB2 Relationship properties |
@asif: as an example, launch the create table UI for SQL Server. Add a field & then click on the "Default Value" section in the bottom of the screen. Type in a value & press the tab key instead of the enter key. You'll notice that your value is not persisted. To persist the value, user has to press the enter key. If we run ADS v17 w/ the 1.7 jre, this problem does not exist. You are able to use either the tab or the enter key & the value persists.
I recall for Import, that we had similar issues w/ the pressing the tab key & the value not persisting. But import doesn't use EditableListOption. However, possibly whatever you did to fix the import scenario could also be applied here?
Also note that I tried running ADS v17 w/ the 1.8.0_72 jre. The tab problem still exists.