-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
4.0.4 snapshot #86
4.0.4 snapshot #86
Conversation
bpangburn
commented
Mar 18, 2021
- SSBaseComboBox.updateOption(). Combo editor was not updating consistently. See SSDBComboBox.updateOption() not always updating combo editor text #85
- Updated Log4j and JUnit Maven dependencies.
- Added explicit Maven plugins versions to eliminate warnings.
- Initial fix for Issue Move updateSSComponent() from combo implementations in SSBaseComboBox #46 moving updateSSComponent out of SSComboBox and SSDBComboBox.
If updateOption of current selection, re-select
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only really looked at base combo.
@SuppressWarnings("unchecked") | ||
@Override | ||
public void updateSSComponent() { | ||
// TODO Modify this class similar to updateSSComponent() in SSFormattedTextField and only limit JDBC types accepted | ||
try { | ||
// If initialization is taking place then there won't be any mappings so don't try to update anything yet. | ||
if (!hasItems()) { | ||
return; | ||
} | ||
|
||
// Maybe insures blank in case of later exception. | ||
setSelectionPending(true); | ||
|
||
// SSDBComboBox will generally work with primary key column data queried from the database, which will generally be of data type long. | ||
// SSComboBox is generally used with 2 or 4 byte integer columns. | ||
final String boundColumnText = getBoundColumnText(); | ||
|
||
// LOGGING | ||
logger.debug("{}: getBoundColumnText() - " + boundColumnText, () -> getColumnForLog()); | ||
|
||
// GET THE BOUND VALUE STORED IN THE ROWSET - may throw a NumberFormatException | ||
M targetValue = null; | ||
if ((boundColumnText != null) && !boundColumnText.isEmpty()) { | ||
// https://github.com/bpangburn/swingset/issues/46 | ||
if (this instanceof SSComboBox) { | ||
targetValue = (M)(Object)Integer.parseInt(boundColumnText); | ||
} else if (this instanceof SSDBComboBox) { | ||
targetValue = (M)(Object)Long.parseLong(boundColumnText); | ||
} else { | ||
throw new Exception(); | ||
} | ||
} | ||
|
||
// LOGGING | ||
logger.debug("{}: targetValue - " + targetValue, () -> getColumnForLog()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Patch on the way to minimize unchecked scope and avoid creating StringBuilder when not logging
Minimize unchecked scope. Avoid StringBuilder in logging
… into 4.0.4-SNAPSHOT
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple of comments on the comments. Which may, or may not, be entirely correct, but probably something to consider.
@@ -1484,16 +1481,29 @@ public void setSeperator(final String _separator) { | |||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(can't add this comment above where I want to)
- NOTE: To retain changes made to current RowSet, call updateRow() before
* calling the updateOption() on SSDBComboBox. This only applies if you if you
* are using the SSDBComboBox and SSDataNavigator for record navigation. If you
* are not using the SSDBComboBox for record navigation then there is no need to
* call updateRow() on the RowSet.
A why would be useful for me about this. Maybe the first sentence, could be something like
This method may change the current row without the navigator doing autoupdate.
I'm not sure the suggestion is accurate. And the comment says "current RowSet", would currentRow be more specific? Or maybe this warning is no longer needed given this PRs latest change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree that this comment seems unnecessary. Best practice would be to use SSSyncManager. If a developer is coding up a custom combo navigator then they can make whatever decisions/assumptions they want about when to save changes to a row. I'll push an update removing the comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also added the SSSyncManager tweak to the CHANGELOG.
// TODO: Possible that this block and isSelectedItem variable | ||
// may be eliminated if a bug is discovered/fixed in GlazedLists. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changing what's in the ComboEditor, which may be done indirectly when modifying the current item, might change the currently selected item when STRICT. So something is needed to insure that the selected mapping before the change is the selected mapping after the change. Otherwise the first item in the list becomes selected (as has been seen, and I guess that's what kicks the navigator?)
Notice that the bug glazedlists/glazedlists#702 affects subsequent programmatic changes to the underlying EventList, not the first one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@errael are you saying that we would want to retain the if (isSelectedItem) {
check regardless of whether glazedlists/glazedlists#702 turns out to be a bug and is fixed? In that case we should just eliminate the TODO and possibly replace with a comment similar to what you wrote above?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are you saying that we would want to retain the
if (isSelectedItem) {
check
Yes, that's what I meant. My assumption is that the mapping that was selected before updateOption
is called should be the mapping after the call. Typically, if the selected item is changed, glazed will change the selection.
eliminate the TODO
That works. The comment that's there may need adjustment/clarification.
If, updateOption
doesn't need to maintain the selected mapping, then the if
could be removed after the glazed bug is fixed. I don't recall exactly, but I think the setSelectedItem(item)
is what avoid the glazed bug on the next change.
…t.git into 4.0.4-SNAPSHOT
@@ -1469,12 +1466,6 @@ public void setSeperator(final String _separator) { | |||
* <p> | |||
* If more than one item is present in the combo for that mapping, only the | |||
* first one is changed. | |||
* <p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@errael See JavaDoc removed per code review.
boolean result = false; | ||
|
||
try (Model.Remodel remodel = optionModel.getRemodel()) { | ||
final int index = remodel.getMappings().indexOf(_mapping); | ||
if (index >= 0) { | ||
boolean isSelectedItem = Objects.equals(_mapping, getSelectedMapping()); | ||
remodel.setOption(index, _option); | ||
result = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@errael See updated comments and removal of TODO per code review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool