![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Easy way to copy attrib values between linked modules? Topic Summary: linked module has attribute (and value) - want to copy Created On: 24-Sep-2004 14:03 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
I have two linked modules. Current application is that one is a CP and the other is an associated module. I can traverse the link and "see" the attribute values of the other module (and its objects) but I want to do the following for attribute multiX (module level):
If "multiX" exists on target if not exist multiX in current module, create it copy value from target's multiX to current module. At present I can see both values (string form), but in this instance, multiX is not type string so I can't just "copy" it. ATTRIBUTE: multiX type: "MiscEnum" TYPE: MiscEnum Enumerations: ex 0 wye 1 I had some code that could go to the other module and SEE the attribute values, but I could not get the value to copy over into the current module. Buth the values would print but not copy. Also, I had wanted to have some robustness so that if the object doesn't exist, I wouldn't bother with trying to copy anything. The attached is that same code, but after I "played" with it for a while it got more and more messed up... and it seems like a lot to go through just to copy an attribute's value. Anybody have a clean, easy way? |
|
![]() |
|
![]() |
|
As far as I can tell, you cannot set an "attrRef = attrRef" (see DXL help "Assignment (to attribute)"), you need to set "attrRef = <some variable value>". Therefore, your line:
cpMod.multiSpec = otherMod.multiSpec needs to modify the right side to turn it into a value, but appending double-double quotes: cpMod.multiSpec = otherMod.multiSpec "" For Multi-enumerated's: An alternative option is to query the sourc multi for all its values, and if one is set the set the target using cpMod.multiSpec += <value found in the source> That's real clumsy and only useful if you wish to preserver existing selections in the target (which you don't). - Louie |
|
![]() |
|
![]() |
|
I found my problem. I had created a copy of the attribute in the new module, but somehow it did not get designated and "multivalued", so unless I set it just right... it would cause errors.
NOW, I can write to the old attribute and don't need to worry about "double assigning" it. I still do have a question about terminology, though. The DOORS reference material is not clear on its use of terminology. I'd appreciate a hand. I have a module ATTRIBUTE "multiVx" that is DEFINED to be of ATTRIBUTE type "MultiType". "MultiType" is a multi-enumeration type so that it is comprised of the following members: Name Value Thing 1 763 Thing 2 333 Thing 3 271 Thing 4 666 Thing 5 42 Thing all 998 (I set the values when I define the type.) Now, for the multiVx attribute, I can edit it (at the module level) using the Module Properties menu and, when selected and the "Edit" button clicked, I get a series of check boxes by each of the MEMBERS listed above. I can select one or all of them... just like I would for a multi-enumerated type for an object. 1) What is that "check boxing" called? (value?) If I edit, say, multiVx in the source module and check box "Thing 1, Thing 2, Thing 4, and Thing all" then, I can see the checked items. string HoldIt = sourceMod.(multiVx) "" print "The list is: " HoldIt "" and get The list is: Thing 1 Thing 2 Thing 4 Thing all It made no reference to Thing3 or Thing 5 from the type. When I look at the hex for these, I see that a "\n" is between each one. I also want to know WHAT is the "check boxing" called... and what is the "Value" listed above (in the type definition) called... and how do these two impact one another/interact/coexist? A clarification would be appreciated. Edited: 1-Oct-2004 at 12:26 by Kirk Walker |
|
![]() |
|
![]() |
|
TYPE: An attribute "type" defines what sort of information is allowed for an attribute definition; integer, real, boolean, percentage (an integer with min 0 and max 100). Those defined to be base-type "enumerated" is simply a list of options. Types are not single nor multi. In your case, the attrType "MultiType" may be better named "ListOfThings". The 'values' of Types are almost worthless, but they let you do quieres "filter on Things that have value 2 of higher"; but that only makes sense if your Things have a real-world hierarchy (PhaseA=0, PhaseB=1, PhaseC=2 or Pririties of Low=1, Medium=2, or High=3) and you assign corresponding values to them. I don't think type 'values' have much meaning for multi enumerated definitions. The 'colors' of Types let you colorize objects in a view based on some attribute (green for Low, yellow for Medium, red for High). Realistically you need to avoid all light colors, since yellow text on a white background is hard to read (and IMO 'rude'). I've played with but never actually deployed values and colors in any official policy.
Don't confuse 'values' of the type: integer associated with each enumerate, with 'values' of the attribute: actual data about actual things (see below). DEFINITION: An attribute "definition" is a place to store real information. Once the type (the list of options) is creaed, you can add an attribute "definition". which means its an actual attribute. The definition is either "single" or "multi", just as it applies to objects/modules, or history/changebars/changedates. In your case you defined attrDef "mutliVx" to be of type "Multi-Type". VALUE: Once the Definition is defined, you can start adding real information to the module. In your case you can tell the Module which "Things" apply. Typically you want Standard users to modify the Values of attributes (they can change which Things apply), but cannot change the Definition (they need permission to add a Thing to the list). Note that since Standard users typically do not create or modify attributes (definitions), they rarely or never need to know about the names of the attribute Types: it doesn't matter to them if attribute "multiVx" is of type "MultiType" or "ListOfThings". DXL: If you want access to an attrType you need to do something like: AttrType at = find("NameOfType"). From there you can derive the available enumerates using at.size and at.strings. If you want access to the attrDef you need to do something like: AttrDef ad = find("NameOfDefinition"). From there you can query the properties of the attribute with ad.mutli, ad.history etc. (note the preceeding presume the 'current module'; preceed such statements with 'current = mod'). If you want access to the value you do something like: string ValueOfAttr = mod."NameOfDefinition". This will get only those elegible values that you have selected, in your case excluding Thing 3 and Thing 5. Check Boxing, I suppose, is seleting values for the module/object. obj."Implement Priority" = "High" would be called "Setting the object's priority". DXL manipulation of Types and Defs is similar to the user interface. Be sure to manually create what you want in some test module, THEN create a DXL to simuate it. Good luck. - Louie |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.