Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 359498 - MasterDetailsContentNode's property editors don't refresh when the associated property is changed
Summary: MasterDetailsContentNode's property editors don't refresh when the associated...
Status: RESOLVED INVALID
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Sapphire (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Konstantin Komissarchik CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-29 19:10 EDT by Shenxue Zhou CLA
Modified: 2021-11-19 09:21 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Shenxue Zhou CLA 2011-09-29 19:10:18 EDT
MasterDetailsContentNode does listen to the associated element and update the content outline structure. But the property editors in the sections don't refresh their values upon element change event notification.
Comment 1 Shenxue Zhou CLA 2011-09-29 20:42:06 EDT
The bug description isn't very accurate. What I should have said was it needs to listen on parent element for changes on the property associated with the definition. Let me explain:

line 120 of MasterDetailsContentNode class:

this.modelElementProperty = (ImpliedElementProperty) resolve( this.definition.getProperty().getContent() );

I have a use case with a very peculiar custom implied element binding on such a property on my root element. When that property changes between two states, the rest of the model needs to access different parts of the xml file. So the underlying resource for the binding changes. The result is the model element for that property is reconstructed.

MasterDetailsContentNode doesn't handle that case. Once its instance variable this.modelElement is assigned, it's set for the life cycle of the form editor.

I think an easy way to fix it (probably not the best way) is when such a change occurs, all the parts need to be recreated.
Comment 2 Konstantin Komissarchik CLA 2011-09-30 10:34:35 EDT
Based on your description, it sounds like the problem is in your binding and/or lack of @DependsOn annotations. The model element held by an ImpliedElementProperty never changes for the duration of its parent's lifespan. The XML node underlying that element can change, but not the element itself.

I believe what you need to do is to add @DependsOn( "/MySwitch" ) to every property starting with the root of the model that may be affected by the switch. This includes properties inside implied element properties, but not inside list properties or regular element properties.