This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | preference change events when nothing changes | ||
---|---|---|---|
Product: | editor | Reporter: | err <err> |
Component: | Settings | Assignee: | David Strupl <dstrupl> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | vstejskal |
Priority: | P3 | Keywords: | SIMPLEFIX |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
simple patch as outlined
simple patch as outlined |
Description
err
2008-08-03 21:41:08 UTC
Thanks for the patch. Created attachment 66550 [details]
simple patch as outlined
Created attachment 66551 [details]
simple patch as outlined
Attached the patch as described, does the equals to guarantee no NPE. (got a time out during the attach, reposted; that's why there are two of them) Integrated into 'main-golden', available in build *200808080201* on http://bits.netbeans.org/dev/nightly/ Changeset: http://hg.netbeans.org/main/rev/68f1d8fc781f User: Vita Stejskal <vstejskal@netbeans.org> Log: #142723 (fixed): applying Ernie's patch for preference change events when nothing changes jVi uses the following private static class TabSetListener implements PreferenceChangeListener { public void preferenceChange(PreferenceChangeEvent evt) { .... || SimpleValueNames.SPACES_PER_TAB.equals(settingName) || SimpleValueNames.INDENT_SHIFT_WIDTH.equals(settingName) || SimpleValueNames.EXPAND_TABS.equals(settingName) || SimpleValueNames.TAB_SIZE.equals(settingName)) to detect changes made in the editor options panel and put up a dialog if these are changed which warns that jVi will override these changes. The patch with this issue is now part of editor.settings.storage's PreferencesImpl.java. This used to fix the problem but no longer does. I have not determined exactly where the event to fire is getting added (I'm seeing all 4 of these events) but I'm wondering if perhaps FormattingPanelController/ProxyPreferences is relatively new or has been substantially reworked. I have verified that the code in the patch is not invoked when I hit the OK button; and also that it is invoked when jVi sets one of the options by doing "prefs.putInt(...)" for example. You could be right. A lot of code around formatting settings panels was added/rewritten. The events in question (see below for the precise source) have a "newValue" of null. I'm thinking that for now I can just ignore the events with null newValue. What do you think? Additional question. What is the following (probably about those per project settings)? Does jVi care about this? FormattingPanelController.OVERRIDE_GLOBAL_FORMATTING_OPTIONS BTW, should I file an issue about the new per project settings interfering with per file settings that jVi wants to maintain? Product Version: NetBeans IDE 6.5 RC1 (Build 200810171318) Java: 1.6.0_07; Java HotSpot(TM) Client VM 10.0-b23 System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb) Userdir: C:\Documents and Settings\erra\.netbeans\6.5rc1 === === Precise source of events === The source of the events can be traced to public final class FormattingPanelController extends OptionsPanelController { ..... public void applyChanges() { .... // and make sure that they do NOT override basic settings from All Languages for(String mimeType : mimeTypes) { Preferences prefs = MimeLookup.getLookup(mimeType).lookup(Preferences.class); prefs.remove(SimpleValueNames.EXPAND_TABS); prefs.remove(SimpleValueNames.INDENT_SHIFT_WIDTH); prefs.remove(SimpleValueNames.SPACES_PER_TAB); prefs.remove(SimpleValueNames.TAB_SIZE); prefs.remove(SimpleValueNames.TEXT_LIMIT_WIDTH); } arrived at as shown in the following stack trace "AWT-EventQueue-1" java.util.prefs.AbstractPreferences.enqueuePreferenceChangeEvent(AbstractPreferences.java:1527) java.util.prefs.AbstractPreferences.remove(AbstractPreferences.java:298) org.netbeans.modules.options.indentation.ProxyPreferences.flush(ProxyPreferences.java:473) org.netbeans.modules.options.indentation.FormattingPanelController$MimeLookupPreferencesFactory.applyChanges(FormattingPanelController.java:280) org.netbeans.modules.options.indentation.FormattingPanelController.applyChanges(FormattingPanelController.java:119) org.netbeans.modules.options.TabbedController.applyChanges(TabbedController.java:112) org.netbeans.modules.options.CategoryModel$Category.applyChanges(CategoryModel.java:387) org.netbeans.modules.options.CategoryModel$Category.access$1000(CategoryModel.java:311) org.netbeans.modules.options.CategoryModel.save(CategoryModel.java:213) org.netbeans.modules.options.OptionsPanel.save(OptionsPanel.java:202) org.netbeans.modules.options.OptionsDisplayerImpl$OptionsPanelListener.actionPerformed(OptionsDisplayerImpl.java:257) org.netbeans.core.windows.services.NbPresenter$ButtonListener.actionPerformed(NbPresenter.java:1137) .... BTW, in the loop for(String mimeType : mimeTypes) { there were around 24 mimeTypes in the situation I observed. I fixed http://hg.netbeans.org/main/rev/ae45de1d253d, could you please try it again? Thanks > I'm thinking that for now I can just ignore the events with null newValue. What do you think? This should be fixed with the above changeset. > FormattingPanelController.OVERRIDE_GLOBAL_FORMATTING_OPTIONS You can ignore this one. > BTW, should I file an issue about the new per project settings interfering with per file settings > that jVi wants to maintain? Umm, I'm not sure. In general, Netbeans does not support per-file formatting settings and there no plans to do so. I think the approach jVi uses is a reasonable compromise. I think jVi should listen on per-project formatting settings the same way as it listens on MimeLookup and display the same warning. Integrated into 'main-golden', will be available in build *200811061401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/ae45de1d253d User: Vita Stejskal <vstejskal@netbeans.org> Log: #142723 - don't fire unneccessary events I guess we can close this one? Or is there anything left unapplied? This was fixed by Vita some time ago. No new information so closing for now as fixed. |