Hi,
/*
*/
// prevent dxl timeout dialog
pragma runLim, 0
Buffer bsz = create
void endAttributeDXL()
{
if (!null obj && attrDXLName != "")
{
obj.attrDXLName = richText tempStringOf(bsz)
}
delete bsz
}
void displayRich(string s)
{
bsz += s
bsz += "\n"
}
//**********
pragma runLim, 0
string limitModules[1] = {"49eec8ce7f156cde-00003560"}
void showOut(Object o, int depth)
{
// the DXL code for the attribute
}
showOut(obj,1)
//**********
endAttributeDXL()
PDU - Wed Oct 05 12:11:31 EDT 2011 |
Re: DXL attribut computed using value of another atrribut don't work [] this is the code for AtrrB [] the "DXL code for the attribute" looks for outgoing links and extracts the value of AttrA from the object on the other side of the link; perhaps displayRich(oOther."AttrA") [] Your view contains a column for AttrB and contains ObjectB. [] Looking at it the AttrB column for ObjectB correctly displays the info from its linked partner ObjectA.AttrA; even when ObjectA isn't in the view. [] When you export that, the value exported changes when ObjectA is not also exported. [] AttrA does not get AttrB's value; otherwise you got a loop problem. I'm a little confused: [] If both objects are in the same module, then both objects have both attributes AttrA and AttrB. [] "it is the same when i export to Word"? What does that mean? If the above is true then I'm stumped. If you are saying the AttrB column value is incorrect for ObjectB when ObjectA is not displayed (and so this has nothing to do with exporting), then I'd say you have some problem: [] AttrA is gathering info about AttrB [] AttrB calculates from the other object AttrA no matter which side of the link its on; thus ObjB.AttrB uses ObjA.AttrA value, but ObjA.AttrA value is based on ObjB.AttrB value; you need to have a car to drive to the dealership to buy a car because you don't have one; and we'll let the interpreter figure it out. [] No way you are trying to display COLUMN values of the other object are you?
|
Re: DXL attribut computed using value of another atrribut don't work llandale - Wed Oct 05 13:23:55 EDT 2011
Hum, i need explain better !
s = probeRichAttr_(othero,"AttrA", false) displayRich(s)
AttrA is well computed
==> AttrB is well computed
==> AttrB is empty !!!
|
Re: DXL attribut computed using value of another atrribut don't work PDU - Thu Oct 06 03:03:46 EDT 2011
Hum, i need explain better !
s = probeRichAttr_(othero,"AttrA", false) displayRich(s)
AttrA is well computed
==> AttrB is well computed
==> AttrB is empty !!!
I'm having some issues where the attr-DXL in one column gets the value intended for the other column. Not sure what to think about that. I think it has to do with attr-DXL that is in an adjacent column.
|
Re: DXL attribut computed using value of another atrribut don't work llandale - Thu Oct 06 16:20:58 EDT 2011
|
Re: DXL attribut computed using value of another atrribut don't work llandale - Thu Oct 06 16:27:49 EDT 2011 The scenario working fine :
AttrA is well computed
Same process before export to Word :
This a solution, but not very good. my question : Is it possible to provoke the calculation of AttrA and AttrB, in this order, without showing AttrA? What I read in the help persuades me that not : the DXL code is not executed when the containing module is opened, but when some event occurs that causes the attribute to be accessed. For example, the event could be because the attribute is being displayed in a column, or because the user opens the Formal Object Editor window on an object with a DXL attribute value. I hope i am wrong. Pierre |
Re: DXL attribut computed using value of another atrribut don't work PDU - Fri Oct 07 02:28:55 EDT 2011
AttrA is well computed
Same process before export to Word :
This a solution, but not very good. my question : Is it possible to provoke the calculation of AttrA and AttrB, in this order, without showing AttrA? What I read in the help persuades me that not : the DXL code is not executed when the containing module is opened, but when some event occurs that causes the attribute to be accessed. For example, the event could be because the attribute is being displayed in a column, or because the user opens the Formal Object Editor window on an object with a DXL attribute value. I hope i am wrong. Pierre Seems to me that the likely order of resolutions are as follows: [1] You have extra Attr-DXL or Layouts adjacent to AttrA or AttrB in your view, and this exasperates a bug I have found in DOORS. Remove all other attrDXL and layouts and try again. This is the ONLY time I've seen Attr-DXL incorrectly calculate; I've done what you have described several times. (OK 'only' isn't quite true, there is also circular references and there are issues with module-level attr-DXL). [2] You have made a mistake; your code is slightly different than you have described. If you don't want to post all the code here then email me directly, I promise to delete all traces after looking at it. louie dot landale at ngc dot com [3] There is something I don't understand. Again, looking at all the code will likely let me figure out what that is and then I will understand it, and then you will understand, and then your code will work.
|
Re: DXL attribut computed using value of another atrribut don't work llandale - Fri Oct 07 13:19:13 EDT 2011
thank you very much for your help. My major objective is not as long as the values in the viewsare correct, but as the export towards Word is good. We export by using TREK, by using a view containing only the main column. Find the two scripts zipped in an attached file. Description in the header of the scripts. Pierre Attachments attachment_14691135_Scripts_DXL.zip |
Re: DXL attribut computed using value of another atrribut don't work PDU - Mon Oct 10 03:00:21 EDT 2011 Rappel_Objectsif.dxl:
Num_Objectif-Test.dxl
Lets look at Num_Objectif-Test.dxl and presume you have 4 objects numbered 1 through 4, each is "below" the other so object #4 is at level 4. If I read the code correctly, the Attr DXL has nothing to say when it runs for objects 1, 3, and 4, because their "WEXP Template" values are not "Titre_Objectif" nor "Titre_Procedure_Test", whose values seem to be reserved for object #2. Therefore, querying this attr DXL for object #3 and #4 will result in calculations that return nothing; unless your first query the value for #2. However, when you query object #2 then it sets the values for #3 and #4. So if you display #3 you presumably also display #2 and therefore #3 gets set OK. But if you don't display #3 (and therefore not #2) but display the object that links to #3, it will query that value which is null, because the attr DXL for #2 has not yet run. Do I guess correctly that lower level objects link directly to these children and grandchildren, objects #3 and #4? The fundamental problem here is that your Num_Objectif-Test.dxl code in attribute Num_Objectif-Test is performing operations outside its intended scope; in this case its setting attribute values of its descendants. Worse, those children attr values are the same ones as the original AttrDXL. Your linking code presumes those values are set when they are not. [1] You should re-arrange the AttrDXL code such that it calculates the value for the CURRENT "obj" only. If my PARENT has "WEXP Template" values of either "Titre_Objectif" or "Titre_Procedure_Test" then I need to calculate as Object #3, likewise if my Grandparent has those value then I need to calculate as per Object #4. You may need to go back to #2 and loop through its children calculating your Indice until you reach your original "obj", trying to figure out "my sequence number" e.g. "06". It will get a little confusing but you will sort it out. [2] If you are commited to this attrocious scope violation you could instead adjust the other DXL, such that it first queries the value of that attribute for the parent and grandparent objects of the linked partner object (ignoring the returned values), before querying the value for the target object, the value you want. This approach may resolve THIS problem, but not for the next time you query that value, perhaps with a filter that ignore object #2; and certainly not for the program 10 months from now who sees that value and wants to use it. Byte the bullet and do [1].
I notice the comments refer to attribute "Num_Objectif_Test", spelled with two underscores, whereas the attr name in the code is "Num_Objectif-Test", spelled with one underscore and one dash. That's a pretty aggrevating for us OCD folks! lol |
Re: DXL attribut computed using value of another atrribut don't work llandale - Mon Oct 10 14:12:09 EDT 2011
Num_Objectif-Test.dxl
Lets look at Num_Objectif-Test.dxl and presume you have 4 objects numbered 1 through 4, each is "below" the other so object #4 is at level 4. If I read the code correctly, the Attr DXL has nothing to say when it runs for objects 1, 3, and 4, because their "WEXP Template" values are not "Titre_Objectif" nor "Titre_Procedure_Test", whose values seem to be reserved for object #2. Therefore, querying this attr DXL for object #3 and #4 will result in calculations that return nothing; unless your first query the value for #2. However, when you query object #2 then it sets the values for #3 and #4. So if you display #3 you presumably also display #2 and therefore #3 gets set OK. But if you don't display #3 (and therefore not #2) but display the object that links to #3, it will query that value which is null, because the attr DXL for #2 has not yet run. Do I guess correctly that lower level objects link directly to these children and grandchildren, objects #3 and #4? The fundamental problem here is that your Num_Objectif-Test.dxl code in attribute Num_Objectif-Test is performing operations outside its intended scope; in this case its setting attribute values of its descendants. Worse, those children attr values are the same ones as the original AttrDXL. Your linking code presumes those values are set when they are not. [1] You should re-arrange the AttrDXL code such that it calculates the value for the CURRENT "obj" only. If my PARENT has "WEXP Template" values of either "Titre_Objectif" or "Titre_Procedure_Test" then I need to calculate as Object #3, likewise if my Grandparent has those value then I need to calculate as per Object #4. You may need to go back to #2 and loop through its children calculating your Indice until you reach your original "obj", trying to figure out "my sequence number" e.g. "06". It will get a little confusing but you will sort it out. [2] If you are commited to this attrocious scope violation you could instead adjust the other DXL, such that it first queries the value of that attribute for the parent and grandparent objects of the linked partner object (ignoring the returned values), before querying the value for the target object, the value you want. This approach may resolve THIS problem, but not for the next time you query that value, perhaps with a filter that ignore object #2; and certainly not for the program 10 months from now who sees that value and wants to use it. Byte the bullet and do [1].
I notice the comments refer to attribute "Num_Objectif_Test", spelled with two underscores, whereas the attr name in the code is "Num_Objectif-Test", spelled with one underscore and one dash. That's a pretty aggrevating for us OCD folks! lol [1] is the solution. code is less beautiful, Every CURRENT object has to go back its genealogy, then come down again until him .. but works fine always. Thanks again. Pierre |