![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Enumerated Types and Default Values Topic Summary: Illogical handling of setting a new default value? Created On: 2-May-2006 13:41 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
I have a module which has an enumerated type attribute "Version No", which has two possible values "v1.1" and "v1.2". "v1.1" being the default value.
If I add a new value "v2.0" which I want to make the new default for all subsequently added objects, I would expect this value to only be used when i create a new object. However, what appears to happen is that for all previously created objects for which no specific value was supplied (e.g. they just used whatever the default was at the time they were created), their "Version No" changes to the new default. I tested this by creating an object and, before adding the new value and default, setting the objects "Version No" attribute to be "v1.2", then to "v1.1", thereby keeping it as the default, but forcibly setting it myself. If I then add the new value and change the default as previously described, the new object maintans the attribute setting I originally gave it, rather than automatically changing to "v2.0". Am I assuming something in the use of the default value of an enumerated type that I shouldn't be, as to me this isn't logical? |
|
![]() |
|
![]() |
|
Anything that doesn't have an explicit value takes on the default - whatever the default currently is.
I think what you need to do is before setting the new value as default, filter on everything with the old default value and then set the value explicitly to the old default. Do this with the object properties sheet and set for current display set. Then you can set your new default value. Hazel |
|
![]() |
|
![]() |
|
Attributes with properties Default and/or Inherited allow object-attributes that have not been given a specific value to display the default or inherited value instead. If an object-attribute does have a specific value then the default or inheritied properties are ignored, even [1] when you change the default or inherited value, and [2] even if the specific valuy IS also the defaulted or inheritied value.
So when you gave that object the value "1.1" its not longer defaulted, and it retains its "1.1" value even when you change the default. So in your case, you see an object-attribute of "1.1" and you wonder whether its being defaulted or if it has an actual value of "1.1". Only your DXL exper knows for sure. Unavailable via the normal interface, there is a DXL perm "hasSpecificValue" that is used to determine if an object-attribute has some actual set value, or if its being defaulted or inherited. I personally dislike defaulted and inherited values, except default of "false" for boolean makes some sense, and an attribute like "ObjectOwner" may lend itself well to being inheritied: set section 3.2 to be owned by "Smith" and all its objects are owned by Smith, unless specifically changed. The attached DXL may be useful. In the GUI you should see there is some sort of "Set to Default" extra enumeration you could have set the object-attribute to. In DXL, you can cause an object-attribute to revert to the true defaulted or inherited value by assigning it a null value: obj.NameAttr = "". - Louie |
|
![]() |
|
![]() |
|
Just read Hazel's reply, and it made me want to add some more comments.
The DXL expression Value = obj.NameAttr will return the value whether its defaulted or not. So you can set the values explicitely via the attached DXL. - Louie |
|
![]() |
|
![]() |
|
Thanks for the replies, you have confirmed my understanding of how the default value works, and the workarounds are useful, thanks again. |
|
![]() |
|
![]() |
|
I doubt there's any DXL programmer that would use the word "elegant" in their work, "unintuitively clumsy" has got to be closer, but I digress....
You have a good point, but on the other hand the user ..err.. the reader really doesn't care if its an actual or defaulted value. The owner of the module DOES care, and you are right there's no nice way for him to know. - Louie |
|
![]() |
Telelogic DOORS
» General Discussion
»
Enumerated Types and Default Values
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.