Community
Participate
Working Groups
Build Identifier: M20110210-1200 I have a LaunchConfigurationTab that sets a single attribute of type Map<String, String>. the relevant code looks like this: private Map<String, String> mTargets = new HashMap<String, String>(); public void createControl(final Composite parent) { [...] myWidget.addModifyListener(new ModifyListener() { @Override public void modifyText(final ModifyEvent e) { mTargets.put("widgetID", mtext.getText()); updateLaunchConfigurationDialog(); } }); [...] } public void setDefaults(final ILaunchConfigurationWorkingCopy configuration) { configuration.setAttribute(UnitTestConstants.PROPERTY_TARGET, new HashMap<String, String>()); } public void initializeFrom(final ILaunchConfiguration configuration) { mTargets = configuration.getAttribute(UnitTestConstants.PROPERTY_TARGET, new HashMap<String, String>()); } public void performApply(final ILaunchConfigurationWorkingCopy configuration) { configuration.setAttribute(UnitTestConstants.PROPERTY_TARGET, mTargets); } doing it this way I end up with the very same hashmap (same object ID) in the ILaunchConfigurationWorkingCopy. When both configs are compared in LaunchConfigurationInfo.compareAttributes() both maps are -obviously- the same. Therefore the "apply" button will not be enabled. My workaround for this is to change my modifyListener to myWidget.addModifyListener(new ModifyListener() { @Override public void modifyText(final ModifyEvent e) { mTargets = new HashMap<String, String>(mTargets); mTargets.put("widgetID", mtext.getText()); updateLaunchConfigurationDialog(); } }); Then my config tab works as expected. Shouldn't LaunchConfigurationInfo work on a copy of the original Map? Reproducible: Always Steps to Reproduce: see details
I think the workaround is the correct implementation. Making a copy of the map for every getAttribute() call could be expensive. A good compromise would be to return the map and list attributes in a read-only wrapper, but I think that this would technically be a breaking API change. Any other options?
Testing an example pretty much identical to the posted one (minus the initializeFrom and setDefaults impls) I do get the Apply / Revert buttons enabling as expected and the maps do have different object ids - I am also testing on 3.7.1. I did notice though that pressing the revert button does not work - it stays enabled even after pressing it. Off the top of my head I don't recall us changing anything in LaunchConfigurationInfo since 3.6. Christian, can you try 3.7 to see if the problem persists? Also note that you can provide a launch configuration comparator to do attribute comparisons yourself using the launchConfigurationComparators extension point from org.eclipse.debug.core.
(In reply to comment #2) > Testing an example pretty much identical to the posted one (minus the > initializeFrom and setDefaults impls) I do get the Apply / Revert buttons > enabling as expected and the maps do have different object ids - I am also > testing on 3.7.1. I did notice though that pressing the revert button does not > work - it stays enabled even after pressing it. Without initializeFrom, where do you get your stored config data from a previous launch from? > Off the top of my head I don't recall us changing anything in > LaunchConfigurationInfo since 3.6. Christian, can you try 3.7 to see if the > problem persists? It still persists in the same way. If the way described in comment #1 is the intended way, maybe this should be mentioned in the documentation. > Also note that you can provide a launch configuration comparator to do > attribute comparisons yourself using the launchConfigurationComparators > extension point from org.eclipse.debug.core. Thanks for pointing this out. I will give it a try.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
