Need triggered dxl to place user in edit mode on enumerated attribute

Mathias Mamsch - Tue Mar 16 06:45:34 EDT 2010

I guess it is not possible. Since DOORS 8.2 there is an int getInPlaceColumn(Module) perm which returns the column that is currently beeing edited (-1 if the editor is not active), but there is no setInPlaceColumnIndex(Module, int) perm.
 

print (getInPlaceColumnIndex current) ""

What you could do is show an editor window:

show editor (obj.sAttrName)

Regards, Mathias

dedawson - Tue Mar 16 11:35:03 EDT 2010
Thanks Mathias. Looks as if your assessment is correct. It can't be done.

On the off-chance someone may see an alternate approach, the following provides a more detailed view of what I was trying to accomplish.

Management has mandated the gathering of monthly volatility metrics, including the number of requirements modified. Being fully aware of the old GIGO principle, I wanted a means of determining if modifications to an object were technical or merely editorial since, from a volatility standpoint, purely editorial changes should not be considered. The approach I took was to define an enumerated attribute 'ChangeType' that would have a default value of Uneval, and user selectable enumerations of Technical and Editorial. Then, whenever an engineer modified object text, a trigger would reset the ChangeType to Uneval, and the engineer would be expected to reset it to reflect the nature of his change. I would then be able to extract this value by processing history records for the metrics collection period.

Realizing that engineers are not exactly prone to following processes, I decided to look for a way to ensure that they reset any ChangeTypes that had been set to Uneval by the Object Text trigger, which led to the opening of this thread.

After playing around with your suggestion, I believe it's likely best to let sleeping dogs lie. While the Edit mode does provide access, there are two significant failure modes:

The trigger that would call it does not fire until after the Object Text modification has been saved, most likely by clicking away from it, in which case the Edit would be initiated on the wrong object.

In cases in which Object Text updates were made via spreadsheet import, the Edit mode would be initiated on the last object imported only.

SystemAdmin - Tue Mar 16 11:43:17 EDT 2010
You could poke through the histories of objects, looking for modifications to particular attributes.

DXL Help >> Modules >> History

dedawson - Tue Mar 16 12:05:16 EDT 2010
That's how I'm gathering the metrics. The problem is in mechanizing a means of ensuring the history record is created. If the user doesn't modify the attribute, I'm out of luck.

SystemAdmin - Tue Mar 16 12:22:35 EDT 2010
Well, speaking from my strict DO-178B avionics point-of-view, a change is a change. If I change a requirement for any reason, be it editorial or functional, that change has to be tracked. Effort is expended to review and trace every change. So in my humble opinion, any change is "volatile". But that's just the industry I work in.

If pure history doesn't do it for you, and triggers don't fill in the gap, then how about something a little more drastic? Create a GUI form for engineers to change attributes, one that forces them to make the editorial vs. technical decision before moving on. I've done something similar for verification people doing reviews.

dedawson - Tue Mar 16 12:47:43 EDT 2010
Hadn't thought of the 'write my own' GUI approach, but that may well solve the interactive part of the problem. Which will have the added benefit(?) of dragging me kicking and screaming down the dxl GUI learning curve. As for updates via imports, a different approach will still be required. May have to require .tsv with both Object and ChangeType, then do import via dxl that disables trigger, does import, and then re-enables trigger.

Thanks for nudging the brain. Different eyes are always a good way to see different approaches.

On the more general topic, from a specification CM point of view, yes, a change is a change, and must be properly identified and accounted for when the next version of the spec is released. When defining volatility from the point of view of 'is this change going to require system or software modifications or require any new or regression testing' however, editorial changes should be ignored. Same general DO-178B industry, by the way.

SystemAdmin - Tue Mar 16 13:07:32 EDT 2010
I see your point. Which leads me to think of something else you might want to consider: suspect links. We don't use them here (yet), but if you're unfamiliar with them you should look them up.

Rational DOORS Help >> Tracking changes and traceability >> Suspect links

Finally, DXL GUI is pretty simple, as long as you don't want to do anything terribly complicated. I was an embedded software engineer before, who never did anything like GUI programming, and I picked up the DXL GUI fairly quickly. It's amazing how well you can corral engineers into following your process by making them use a form.

roybond - Tue Mar 16 13:55:05 EDT 2010
What you need is a Pre Save Trigger, which then launches a dialog box.

I have a similar mechanism which is launches a Dialog Box following a change to Object Text, within which the User MUST provide a Justification for the change. If the User attempts to cancel the Dialog Box or continue without providing 'some text', the change is discarded.

You could use this mechanism to provide a Drop Down selector to the User from which they MUST select a value to continue.
roy.bond@baesystems.com

dedawson - Tue Mar 16 16:47:37 EDT 2010
Sounds as if the last piece of the puzzle just fell into place. I'm assuming the difference between pre- and post-save triggers is that both fire upon exiting the editing of object text, but the pre-save expects confirmation that the change is to be saved, whereas post-save doesn't care.

many thanks,

david