Summary: | ClassCastException out of Launch history preference page | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Darin Swanson <Darin_Swanson> |
Component: | Debug | Assignee: | Darin Swanson <Darin_Swanson> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | critical | ||
Priority: | P1 | CC: | carolynmacleod4, darin.eclipse, erich_gamma, jeem, Kevin_McGuire, n.a.edgar |
Version: | 2.0 | ||
Target Milestone: | 2.0 F2 | ||
Hardware: | PC | ||
OS: | other | ||
Whiteboard: |
Description
Darin Swanson
2002-05-22 14:42:58 EDT
*** Bug 17734 has been marked as a duplicate of this bug. *** This looks like a bug with IntegerFieldEditor. Test case: Set breakpoint in LaunchConfigurationManager in propertyChange(). Key in change to max history size field, click Apply. Note that 'new value' is an Integer, as expected. Now, click 'Restore Defaults' button, then Apply. Note that 'new value' is now a String, not expected. Moving to UI. This is the way the preferences work, although it is understandably confusing. Since the preferences are not actually individually typed, the type of object in the callback depends on which call is used to change the value. With setValue(String, int) the value is an Integer or null. With setToDefault (String) the value is a String or null. See the method specs on Preferences. Listeners need to be prepared to handle both Integer and String values (and null). Alternatively, listeners can always ignore the values in the event and get the new value from the preferences. There are several places that need fixing up: Compare: org.eclipse.compare.internal.Utilities.getValue(PropertyChangeEvent, boolean) Debug: org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfigurationManager.p ropertyChange(PropertyChangeEvent) JDT Debug: org.eclipse.jdt.internal.debug.ui.actions.ToggleStepFilterAction.propertyChange (PropertyChangeEvent) org.eclipse.jdt.internal.debug.ui.JavaDebugOptionsManager.propertyChange (PropertyChangeEvent) (2 matches) UI: org.eclipse.ui.internal.WorkbenchActionBuilder.propertyChange (PropertyChangeEvent) Team: org.eclipse.team.internal.ccvs.ui.CVSUIPlugin.propertyChange (PropertyChangeEvent) I'll file separate PRs for these. Teams should double-check all senders of org.eclipse.jface.util.PropertyChangeEvent.getNewValue() and getOldValue(). Reassigning this one back to Debug. The new runtime-level Preferences mechanism has the same pattern. Should double-check refs to org.eclipse.core.runtime.Preferences.PropertyChangeEvent as well as the JFace one. Filed the following bugs for each of the components above: Compare: bug 17889 JDT-Debug: bug 17890 Team: bug 17891 Platform-UI: bug 17892 Fixed. Please verify. Verified. |