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.
You cannot change multiple properties at once if properties are different and using a custom editor. An example is Key Bindings property in Editor settings (Options). Being able ti modify multiple properties at once is important to us (Sun Studio) product because we rely heavily on properties and custom editors. There are other problems with changing multiple properties at once even with standard editors like the '...' button not always being show. The following modifications to PropUtils.java in the org.openide.explorer.propertysheet package seem to somewhat fix these problems: >>>>>>>>>>>>>>>>> diff -c PropUtils.java- PropUtils.java *** PropUtils.java- Wed Mar 16 00:18:08 2005 --- PropUtils.java Wed Jun 29 17:47:54 2005 *************** *** 678,684 **** } public java.awt.Component getCustomEditor() { ! return null;//ed.getCustomEditor(); } public String getJavaInitializationString() { --- 678,684 ---- } public java.awt.Component getCustomEditor() { ! return ed.getCustomEditor(); } public String getJavaInitializationString() { *************** *** 725,731 **** } public boolean supportsCustomEditor() { ! return false; } } --- 725,731 ---- } public boolean supportsCustomEditor() { ! return true; } } Are they safe? Is there a better fix?
Targeted for 4.2, right? I'm not sure why the code was uncommented - maybe there was some reason. I'll try to look at it for 4.2. Also I saw that you already used the patch for the deimos branch. So tell me if you encounter any problem, thanks ;)
Yes, we will use my 'fix' in deimos for now and I will let you know whether we find any side effects from these changes. As you noticed, all I did was un-doing somebody elses 'fix', but I don't understand the details. I may have missed one or two places. Perhaps the CVS history can uncover what the purpose was behind the other 'fix'. I'm interested in porting back your fix in 4.2 to deimos branch.
> As you noticed, all I did was un-doing somebody elses 'fix', > but I don't understand the details. Yes, me neither. Anyway somebody had a reason for doing so. I will take a look into the history and eventually ask the commiter (95% Tim Boudreau :) ) if it is necessary.
thp, any experience with your fix? Thanks. Tim, did you have any reason to uncomment the support for a custom editor in DifferentValuesEditor? (the history was lost after openide-split). Thanks for comment if you recall something.
This was disabled explicitly because it was impossible to do 100% reliably. The problem being - what value do you take as the value that the editor should have when the custom editor is invoked? If null, some custom editors will throw an exception. Then, how do you know when the value is changed? It will depend on how the custom editor is implemented (everybody has their own idea of the right way to do this). Just getting it so that simply bringing up the custom editor will not, in some cases, set the value of all selected properties to the value of whichever arbitrary editor's custom editor you chose to use may be impossible. Lastly, what do you do about mutual exclusion? Say, I select five files in the same directory, and bring up the custom editor on their Name property - what should be the failure behavior - depending on the ordering of the selection, one property has been successfully set. I'd suggest making it the responsibility of the Property to explicitly state that it can actually do something reasonable, and keep the default behavior. I.e. if (Boolean.TRUE.equals(theProperty.getValue("multiSelectCustomEditors"))) on every Property being proxied then return true for supportsCustomEditor() (good luck deciding which property's custom editor to use - you can invoke this over properties that do not even have the same value type if their name is the same). If it is made the default behavior, you're pretty much guaranteed it will throw exceptions in some cases. The root problem is that the interface for custom editors in the beans spec is under-specified.
Thanks for your information, Tim. I understand now. Than I suppose we have to consider the right behaviour with HIE. Will not be enhanced for 5.0 - feature frozen, too risky.
But we (Deimos) depend on this feature and need it to work in 4.2 (5.0?) when we move to that release. We use build configurations in Deimos. A configuration is basically a property sheet and it is a crucial feature that you can edit multiple configurations at once. I 'fixed' it in our own branch 'deimos' and don't see any bad problems. Please reconsider for 4.2 (5.0?). Thanks.
Do as you wish. I'd say enabling it by a hint should be near 0 risk, as long as the existing behavior is kept for any properties that don't have the hint (i.e all properties in NetBeans).
that would work for us (Deimos). Please consider this solution.
Should be simple. I hope I'll have time for it.
Created attachment 24648 [details] Patch - not tested but should work
Thanks Tim, I'll try it.
i think that delegating this responsibility to the property is too restrictive. there's a lot of valid cases where multiple properties editing is desirable, e.g. form designer. (besides the custom edit button does show up even now when input focus moves to other property field). let's see if any serious issues show up because of the fix to #60895 and then we can revisit this again. *** This issue has been marked as a duplicate of 60895 ***
thp, do you consider this issue solved together with the fix for issue #60895? If no, please reopen.
I will verify the fix as soon as possible. We are in the process of moving our source base to 5.0 (trunk) and it will be difficult to test before this has been completed. I may take a few weeks. I will reopen this issue if problems not fixed. Thanks.
Ok, thanks.