Community
Participate
Working Groups
Created attachment 112747 [details] Patch for new method signature Build ID: I20080617-2000 Current types of oldValue and newValue arguments are String. It is not obvious why they are not general Objects as supported by the used PropertyChangeEvent. Therefore I suggest to open this method for clients which want to propagate changes of non-String properties. New method signature: protected void firePartPropertyChanged(String key, Object oldValue, Object newValue) Attached a patch which also provides a JavaDoc proposal to fix Bug 238321.
(In reply to comment #0) > Current types of oldValue and newValue arguments are String. > It is not obvious why they are not general Objects as supported by the used > PropertyChangeEvent. Amongst other things, Part properties must be persisted between sessions. To change it would be feature work, and the direction would probably be similar to how persistible editor inputs are stored in the workbench.xml. See org.eclipse.ui.IElementFactory It is also not as simple as changing this one method ... it was added as a feature for support of org.eclipse.ui.IWorkbenchPart3 and methods like org.eclipse.ui.presentations.IPresentablePart.getPartProperty(String) These part properties are to allow extension on what is already supported, like title, description, dirty, etc ... mostly related to the state of the part in the workbench (that should be displayed by the workbench) as opposed to the "application state" of the model the part contains. PW
Also, the proposed change is not binary compatible, see http://wiki.eclipse.org/Evolving_Java-based_APIs
(In reply to comment #2) Correct. So it's impossible to change the signature. (In reply to comment #1) I don't see any need to change the persistance mechanism for part properties just for getting this method used in a way it wasn't made for. All in all the JavaDoc left me in the dark what to do (and what not) with the offered method. (I just wanted to propagate an IStatus of an editor.) There are always other ways to propagate changes, no matter the property belongs a little more to the WorkbenchPart or more to the model. So it's not a big deal to leave the method as it is. But please fix the JavaDoc bug (Bug 238321) to avoid future requests ;-) Sebastian
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.
