I am trying to take a list of some 100+ values and write them to a list of enumerations. I created this short code, but it stops at the last line and states 'unknown Module attribute (Criteria)'. There most certainly is an attribute with that name, and it is a multi-value type. Am I doing something wrong?
//This script will add a list of values from a .txt file to a list of multi-valued enumerations stevenson - Tue Aug 13 15:43:15 EDT 2013 |
Re: Adding Enumerations It is likely Criteria applies only to Mbjects and not also to the Module. (Equivalently, the "Prefix" system attr applies only to the module and not to Objects).\ If you really want the MODULE to have "Criteria", it's easy to modify the properties to add it (upper right of edit-attributes screen). -Louie I'd be tempted to do this:
|
Re: Adding Enumerations llandale - Tue Aug 13 16:01:59 EDT 2013 It is likely Criteria applies only to Mbjects and not also to the Module. (Equivalently, the "Prefix" system attr applies only to the module and not to Objects).\ If you really want the MODULE to have "Criteria", it's easy to modify the properties to add it (upper right of edit-attributes screen). -Louie I'd be tempted to do this:
I did miss that box thank you. Unfortunately, I can not achieve my end goal. m."Criteria" += ID leads to the error: 'The value '...' is not valid for type 'Criteria'. It doesn't matter whether its an integer, has special characters, or is just a letter. Is it even possible to append options onto an enumerated multi-value attribute other than through manual input? Or am I just missing something? |
Re: Adding Enumerations stevenson - Tue Aug 13 16:15:59 EDT 2013 I did miss that box thank you. Unfortunately, I can not achieve my end goal. m."Criteria" += ID leads to the error: 'The value '...' is not valid for type 'Criteria'. It doesn't matter whether its an integer, has special characters, or is just a letter. Is it even possible to append options onto an enumerated multi-value attribute other than through manual input? Or am I just missing something? The purpose of "enumerations" is to restrict the data that CAN be placed in the attribute. With "Severity" of "High", "Medium", or "Low" one cannot set it to "Harmful". I don't think it reasonably-realistic to continually add valid Enumerations to it's type. You would could the number of current values, create a set if parellel arrays at size one larger, populate them with the current values and then add the new value (and number and color) to the end. Then "modify" the AttrType. For you it seems though you may just want a "Text" attribute and stick a new line in for each new value.
Or I suppose add it if no such complete value is therein. That gets a little sticky; you do want to add value "BCD" when value "ABCDE" is already there. -Louie |
Re: Adding Enumerations llandale - Wed Aug 14 17:01:31 EDT 2013 The purpose of "enumerations" is to restrict the data that CAN be placed in the attribute. With "Severity" of "High", "Medium", or "Low" one cannot set it to "Harmful". I don't think it reasonably-realistic to continually add valid Enumerations to it's type. You would could the number of current values, create a set if parellel arrays at size one larger, populate them with the current values and then add the new value (and number and color) to the end. Then "modify" the AttrType. For you it seems though you may just want a "Text" attribute and stick a new line in for each new value.
Or I suppose add it if no such complete value is therein. That gets a little sticky; you do want to add value "BCD" when value "ABCDE" is already there. -Louie A buffer doesn't really address the issue I'm having. The for loop at the end of my script should append each line of my text file to the multi-valued enumeration, "Criteria".
'm."Criteria" += ID' will not add enumerated options to the value of the attribute since it claims the options 'are not a valid type'.
My objective is to set up a multi-valued enumeration attribute for many modules (between 10-60 each).
|
Re: Adding Enumerations stevenson - Wed Aug 14 17:43:03 EDT 2013 A buffer doesn't really address the issue I'm having. The for loop at the end of my script should append each line of my text file to the multi-valued enumeration, "Criteria".
'm."Criteria" += ID' will not add enumerated options to the value of the attribute since it claims the options 'are not a valid type'.
My objective is to set up a multi-valued enumeration attribute for many modules (between 10-60 each).
A module attribute for this doesn't seem right. It also seems to work strangely. The intent of module attributes are for attributes that are only for the module and not for the objects themselves. People get confused because they think the attribute is for all the objects in the module, so it must be a module attribute, but this is not always the case. For example, Created On is both a module attribute and an Object attribute. For each object, the Created On attribute stores when the object was created. For the module attribute, it stores the date when the module was created (without any objects in it). There should be very few user defined module attributes. One possibility might be the module state, such as _Release, where the module could be in draft, submitted for release, or released. Having a criteria that is for the entire module and NOT for the objects would be very unusual. I uncovered an issue with DOORS 9.3.0.6 where an attribute was set for both Module and Objects and the settings (generate history I believe) would change depending on if you were in read only mode or exclusive edit mode. The fix here was to only make it applicable to Objects and not Module. I think DOORS got confused on which attribute it was looking at, depending on the mode. I've been told that this has been fixed in 9.5. I also tried adding just a Module multi-value enumeration and got some strange stuff. First of all, it asked if I wanted to add it into the view and I accepted that. But when I look at the column properties, it says the contents are the Absolute Number attribute. It obviously is not the Absolute Number attribute, since it doesn't show that. I then edited the column and made different selections for different objects. It accepted these (1st object had Component 1, 2nd object had Component 1 and Component 2). This is also strange because it is only an attribute for the module, so it shouldn't be able to have different values, but only one value. I then tried a dxl to print the module attribute and it only comes back with a null, even if I try and set it. My suggestion is to go back and think if you really want a module attribute. Especially with the idea that it looks like they don't work very well. Other than that, you might try adding two double quotes after the ID in the m.criteria +=ID to ensure it is a string, or maybe casting it (string ID)??? Good luck, Greg |
Re: Adding Enumerations stevenson - Wed Aug 14 17:43:03 EDT 2013 A buffer doesn't really address the issue I'm having. The for loop at the end of my script should append each line of my text file to the multi-valued enumeration, "Criteria".
'm."Criteria" += ID' will not add enumerated options to the value of the attribute since it claims the options 'are not a valid type'.
My objective is to set up a multi-valued enumeration attribute for many modules (between 10-60 each).
So finally. You want to create an object-level enumerated attribute in a bunch of modules, whose enumerations are already edited into some text file. If you want to modify an existing value (e.g. "add" to it) you have a big problem. I think you need to read the DOORS user manual Attributes, making sure you grasp the differences between attributes [1] Types [2] Definitions and [3] Values. "+=" is for setting the value, not for defining the enumerations. Overall, you want to do this:
[A] Look in DXL manual chapter "Attributes" section "Attribute type manipulation" command "create". You want the 3rd one:
You want to read the text file and store the values into a Skip list with KEY int 'Sequence++". Then create the 4 arrays at the right size (Sequence). Then populate the arrays based on the Skip; presumably "values" and "colors" will be all zero and "description" will be blank. Then create the Type. [B] Create the DEF, which may look like this:
[C] and [D] are self explanatory. ----------------------------------------------- Modifying the enumerations is quite a bit harder. I have not solved the problem of tyring to rename some of the enumerations (e.g. rename "Hard" to "Impossible"). But if you figure only to remove some enumerations and add some and preserve some, then:
I'm trying to resolve this problem myself and so far have not succeeded. Good luck. -Louie |
Re: Adding Enumerations GregM_dxler - Thu Aug 15 09:26:19 EDT 2013 A module attribute for this doesn't seem right. It also seems to work strangely. The intent of module attributes are for attributes that are only for the module and not for the objects themselves. People get confused because they think the attribute is for all the objects in the module, so it must be a module attribute, but this is not always the case. For example, Created On is both a module attribute and an Object attribute. For each object, the Created On attribute stores when the object was created. For the module attribute, it stores the date when the module was created (without any objects in it). There should be very few user defined module attributes. One possibility might be the module state, such as _Release, where the module could be in draft, submitted for release, or released. Having a criteria that is for the entire module and NOT for the objects would be very unusual. I uncovered an issue with DOORS 9.3.0.6 where an attribute was set for both Module and Objects and the settings (generate history I believe) would change depending on if you were in read only mode or exclusive edit mode. The fix here was to only make it applicable to Objects and not Module. I think DOORS got confused on which attribute it was looking at, depending on the mode. I've been told that this has been fixed in 9.5. I also tried adding just a Module multi-value enumeration and got some strange stuff. First of all, it asked if I wanted to add it into the view and I accepted that. But when I look at the column properties, it says the contents are the Absolute Number attribute. It obviously is not the Absolute Number attribute, since it doesn't show that. I then edited the column and made different selections for different objects. It accepted these (1st object had Component 1, 2nd object had Component 1 and Component 2). This is also strange because it is only an attribute for the module, so it shouldn't be able to have different values, but only one value. I then tried a dxl to print the module attribute and it only comes back with a null, even if I try and set it. My suggestion is to go back and think if you really want a module attribute. Especially with the idea that it looks like they don't work very well. Other than that, you might try adding two double quotes after the ID in the m.criteria +=ID to ensure it is a string, or maybe casting it (string ID)??? Good luck, Greg Not sure users should be creating ANY attributes. Even if some module-admin wants an attribute, it is likely useful in other modules and the project-admins who architect the project will want to have something to say about that. Yes, few attributes apply both to the module and the objects. We are actually creating a fair number of module-level attributes. Your "_Release" is a good example showing the status of the module. At my first company the Dude had a real good exporter, where certain module-level attributes were set to variables in the Word template and the export was splendid: "Document Number" and "Revision" and perhaps "Book Boss". I've got maintenance scripts that deal with their own attributes "z_LinKing_LastModified". I'm moving toward data driven scripts and will want to specify "ReqID" as the "Key" attribute for this spec; and put "ReqID" into a module-level attribute "KeyAttribute". -Louie As for your "view" of the module-level attribute: there have been other "features" like that. In some past version you could insert an attribute, start editing it's value for an object (in-place editing), then change the column to some system-level attribute, and then finish modifying the value. Thus you could change the "Created By" value of an Object. You can also do funny things like using AttrDXL for a module-level attribute to get a strange "Object" handle on the "Module", and modify object level attributes at the module level. eeeeaaaaack. |
Re: Adding Enumerations llandale - Thu Aug 15 10:41:11 EDT 2013 So finally. You want to create an object-level enumerated attribute in a bunch of modules, whose enumerations are already edited into some text file. If you want to modify an existing value (e.g. "add" to it) you have a big problem. I think you need to read the DOORS user manual Attributes, making sure you grasp the differences between attributes [1] Types [2] Definitions and [3] Values. "+=" is for setting the value, not for defining the enumerations. Overall, you want to do this:
[A] Look in DXL manual chapter "Attributes" section "Attribute type manipulation" command "create". You want the 3rd one:
You want to read the text file and store the values into a Skip list with KEY int 'Sequence++". Then create the 4 arrays at the right size (Sequence). Then populate the arrays based on the Skip; presumably "values" and "colors" will be all zero and "description" will be blank. Then create the Type. [B] Create the DEF, which may look like this:
[C] and [D] are self explanatory. ----------------------------------------------- Modifying the enumerations is quite a bit harder. I have not solved the problem of tyring to rename some of the enumerations (e.g. rename "Hard" to "Impossible"). But if you figure only to remove some enumerations and add some and preserve some, then:
I'm trying to resolve this problem myself and so far have not succeeded. Good luck. -Louie So I'm trying to implement this solution, but I'm a little bit of a novice. I took the example from the DXL reference manual and adapted it to this:
// Adds skip list values to enumeration list
I tried to just use a counter (x) to add all the values from my skip list. This did not work. I know you mentioned using KEY int 'Sequence++". I'm not exactly sure how this works. I've been reading through the Skip lists DXL help and I still can't figure it out. Could you explain it a little more? |
Re: Adding Enumerations stevenson - Thu Aug 15 14:03:20 EDT 2013 So I'm trying to implement this solution, but I'm a little bit of a novice. I took the example from the DXL reference manual and adapted it to this:
// Adds skip list values to enumeration list
I tried to just use a counter (x) to add all the values from my skip list. This did not work. I know you mentioned using KEY int 'Sequence++". I'm not exactly sure how this works. I've been reading through the Skip lists DXL help and I still can't figure it out. Could you explain it a little more?
-Louie |
Re: Adding Enumerations llandale - Thu Aug 15 10:41:11 EDT 2013 So finally. You want to create an object-level enumerated attribute in a bunch of modules, whose enumerations are already edited into some text file. If you want to modify an existing value (e.g. "add" to it) you have a big problem. I think you need to read the DOORS user manual Attributes, making sure you grasp the differences between attributes [1] Types [2] Definitions and [3] Values. "+=" is for setting the value, not for defining the enumerations. Overall, you want to do this:
[A] Look in DXL manual chapter "Attributes" section "Attribute type manipulation" command "create". You want the 3rd one:
You want to read the text file and store the values into a Skip list with KEY int 'Sequence++". Then create the 4 arrays at the right size (Sequence). Then populate the arrays based on the Skip; presumably "values" and "colors" will be all zero and "description" will be blank. Then create the Type. [B] Create the DEF, which may look like this:
[C] and [D] are self explanatory. ----------------------------------------------- Modifying the enumerations is quite a bit harder. I have not solved the problem of tyring to rename some of the enumerations (e.g. rename "Hard" to "Impossible"). But if you figure only to remove some enumerations and add some and preserve some, then:
I'm trying to resolve this problem myself and so far have not succeeded. Good luck. -Louie Renaming, adding, removing 'codes' to an enumerated type is nasty... but there is the function
AttrType modify(AttrType type, I have managed to use that once or twice. Adding a new 'code' at the end of the list is fairly simple. If you are removing a value (not replacing it), first change that value for all of the objects which have that value set. If you are rearraging the order or adding a new 'code' in the middle, the arrMaps array has to be fixed. I seem to remember that for each 'code' in the modified version you have to put the order/number of the original. If it was {Easy, Medium, Hard} and you want that translated to {Simple, OK, Difficult, Impossible} where Easy==Simple, Medium==OK, Hard ==Impossible, I think the arrMaps should be {0, 1, -1, 2}... Well I remember getting it to work once after lots of trial and many errors. /sekrbo |
Re: Adding Enumerations sekrbo - Tue Aug 27 09:05:42 EDT 2013 Renaming, adding, removing 'codes' to an enumerated type is nasty... but there is the function
AttrType modify(AttrType type, I have managed to use that once or twice. Adding a new 'code' at the end of the list is fairly simple. If you are removing a value (not replacing it), first change that value for all of the objects which have that value set. If you are rearraging the order or adding a new 'code' in the middle, the arrMaps array has to be fixed. I seem to remember that for each 'code' in the modified version you have to put the order/number of the original. If it was {Easy, Medium, Hard} and you want that translated to {Simple, OK, Difficult, Impossible} where Easy==Simple, Medium==OK, Hard ==Impossible, I think the arrMaps should be {0, 1, -1, 2}... Well I remember getting it to work once after lots of trial and many errors. /sekrbo {0, 1, -1, 2} looks right. I found it easier once I forced myself to remember that the arrays used in the "modify" command are the same size and all represent information about the desired new set of enumerations: the 3rd position in the array represents the 3rd enumeration you want to end up with. Then it was easier for me to conceptualize the the 3rd position of the Mapping array must point to the equivalent position in the old existing enumerations. An outline of such a script might look like this:
I remind folks that after "modify"ing the enumerations you need to "refresh" the object values; otherwise you will still "see" the old values:
-Louie |