Hi all, Andreas and I already discussed this, but the answer may be of interest to all developers.
> When the attribute of a SpecObject is modified, the it seems that ProR > overrides that so that the related SpecHierarchy is the affectedObject. > Is that true? > What is the intention behind that? The reasoning is that the GUI uses the affectedObject information to update the selection. A SpecObject can be edited directly (by selecting the SpecObject in the outline) or indirectly via a SpecHierarchy (by selecting a SpecHierarchy in the Outline or in the Specification Editor). If it is edited indirectly, then the SpecHierarchy that references the SpecObject is considered the affected Object. Picture a scenario where two SpecHierarchies reference the same SpecObject: +------------+ | SH1 -> SO1 | | SH2 -> SO1 | +------------+ If the user edits SH1 (but really edits SO1) and SO1 would be the affectedObject, after editing, nothing would be selected (as SO1 is not in the view). But if we declare SH1 the affected object, then after editing, SO1 stays selected. I hope this clarifies things. Best, - Michael On 06/03/2012 01:32 PM, Andreas Graf wrote: > Dear all, > > I have almost finished an implementation of changing the lastChange > attribute, taking a recommendation from EdMerks on from one of the > forums from 2009. > During my test, I noticed that ProR seems to use a specific concept of > what the affected object of e.g. the setting of an attribute seems to be. > > When the attribute of a SpecObject is modified, the it seems that ProR > overrides that so that the related SpecHierarchy is the affectedObject. > Is that true? > What is the intention behind that? I would have expected that the > affected object really is the "affected object", i.e. either the > attribute value or the specObject. > > Best Regards, > > Andreas > > -- *Michael Jastram* +49 (162) 274 83 94 http://jastram.de Geschäftsführer Formal Mind GmbH http://formalmind.com Wissenschaftler Heinrich Heine Universität Düsseldorf http://www.stups.uni-duesseldorf.de <http://www.stups.uni-duesseldorf.de/w/Michael_Jastram> Vorsitzender rheinjug e.V. http://rheinjug.de Project Lead Eclipse Requirements Modeling Framework http://eclipse.org/rmf
_______________________________________________ rmf-dev mailing list rmf-dev@eclipse.org http://dev.eclipse.org/mailman/listinfo/rmf-dev
