![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Incorrect display order for enumerated attribute Topic Summary: Created On: 10-Jul-2006 14:06 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
Hello,
We have a multiselect enumerated attribute in one of our modules. Recently I've noticed that it is not displaying in the order that it is declared in the attribute type. That is, the order of the enumerations in the attribute type is as follows: 1.3.2 1.4 1.4.1 2.0 Here is how they are actually displayed in the module in *non*-edit mode (for ones that have all options checked): 1.3.2 1.4.1 1.4 2.0 If you double-click that column to put it in edit mode, the displayed check boxes come up in the correct order. The next odd thing is that if you then click out of edit mode without making any changes, DOORS turns the object change indicator red and corrects the display order. The history shows a change to that attribute, with the old and new values just being a rearrangment of the same values. I have played with the "related number" values and these seem to have no effect. I zeroed them all out (had no effect), then tried putting them all in a sequence (also didn't work), and the display order hasn't changed. I don't think DOORS uses "related number" for display order at all; I think it just keys off the defined order for the enumerated values. Does anybody know why this attribute is not displaying its values in the defined order? Thanks, Kevin Edited: 14-Jul-2006 at 16:35 by Kevin James |
|
![]() |
|
![]() |
|
I saw what you saw when after we changed the order of the enumerations in the attribute type. Old values were displayed the old way until we edited that object. Other than that, the only thing I can think of is that the original values were inserted via a script originally in the wrong order.
- Louie |
|
![]() |
|
![]() |
|
Hey Louie,
Thanks for your reply. I found that the following script corrected our problem: for o in current Module do { o."Attribute Name" = o."Attribute Name" ""; } This edits the current objects with the issue. Any new objects don't experience the issue. Kevin Edited: 11-Jul-2006 at 19:16 by Kevin James |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.