Hi, I have recently started experimenting with DXL attributes. Altough the code snippets I tried out work perfectly, I do not understand how many times does the DXL attribute script run. Sometimes it runs once for each object, sometimes it only runs for the whole module once, of course in case of different scripts. Could somebody explain to me that how this works? valikund - Tue Jul 21 07:07:08 EDT 2015 |
Re: How many times does a DXL atrribute script run In general a DXL attribute is calculated when its first accessed. So when you open a module all DXL Attributes that are also "module" attributes will be calculated. When your module default view tries to show a DXL attribute it will also be calculated. When you have a filter defined over a DXL attribute of course it also needs to be calculated. If a DXL script accesses the attribute, it will be calculated ... So far the theory. In practice DXL attributes will also calculate without a special reason. In not so recent DOORS clients I found, that some DXL attributes were calculated on opening the module, without me knowing from where it was accessed. I also found, that sometimes DXL attributes will calculate only for a few objects (not all). Still - after a DXL attribute has been calculated it will normally not recalculate, except: - You assign the null value to a DXL attribute, forcing it to be recalculated. - You execute the "Refresh Module" or "Refresh DXL Attributes" script (which will internally assign 'null' to a DXL attribute forcing it to recalculate). There is a special case, where the DXL attribute itself returns the value null. I am not sure how this is solved in recent DOORs clients, but for very early DOORS versions this would make the DXL Attribute recalculate constantly (like a DXL Layout). Hope that helps, regards, Mathias
|
Re: How many times does a DXL atrribute script run Slightly different from MMs response: DXL Attribute..
Interpretation: DXL Attributes ..
I have been writing complicated Attr-DXL such that it calculates all object-attrDXL-values in the module. Open link partners, calculate all values, close link partners. This seems to mess up the "refresh" considerations above a little. This takes longer initially of course but you can now close these other modules and scrolling is quick. View Bug:
-Louie |
Re: How many times does a DXL atrribute script run Thank you for your in-depth answers, they helped me a lot to see the situation clearer. My question is, that if the DXL attributes have such an erratic behaviour, isn't it better to use an outside script to set the values periodically? Also, when I write my code, should I write to run for each object separately, for example: string s = "New/changed" obj."Attribute" = s Or is it possible/feasible to write it to run for the whole module, ex.: Module m = current Object o = first m for o in m do{} Which approach should I take? |
Re: How many times does a DXL atrribute script run valikund - Wed Jul 22 02:46:58 EDT 2015 Thank you for your in-depth answers, they helped me a lot to see the situation clearer. My question is, that if the DXL attributes have such an erratic behaviour, isn't it better to use an outside script to set the values periodically? Also, when I write my code, should I write to run for each object separately, for example: string s = "New/changed" obj."Attribute" = s Or is it possible/feasible to write it to run for the whole module, ex.: Module m = current Object o = first m for o in m do{} Which approach should I take? Our answers might have sounded like you shouldn't use DXL Attributes - but you should. From my perspective DXL attributes work fine, as long as you don't try to do 'clever' or 'fancy' things (like having two DXL attributes depend on each other, or set the value of a DXL attribute from some other script, etc.), i.e. try to use the DXL attributes in a way there were not intended. You might not be able to predict, when exactly the calculation is run - but most of the times you do not need to care and you also do not need to care about excessive recalculation. The big advantage of DXL attributes is, that they will also work in read mode, that means you do not need to care if the module can be edited or is in shared edit mode, or if the user has access, etc. I would only use an external calculation if the time to calculate the attribute values is really unbearable for a user. In this case I would simply create a script, put it to the menu, which will check if the module is in edit mode, and if so, update all values (without saving). If everythink worked fine the user can save and close the module.
Regards, Mathias |
Re: How many times does a DXL atrribute script run I know that MM has mentioned it in his previous reply as a possible problem source, but how problematic is it to make two DXL attributes, from which one of the attributes depend on the other. So there isn't a cross dependence, and the two attributes are in different modules.
Regards, Zsolti |
Re: How many times does a DXL atrribute script run valikund - Thu Jul 23 02:53:40 EDT 2015 I know that MM has mentioned it in his previous reply as a possible problem source, but how problematic is it to make two DXL attributes, from which one of the attributes depend on the other. So there isn't a cross dependence, and the two attributes are in different modules.
Regards, Zsolti As long as you do no circular dependecies, you should be fine. One DXL attribute accessing the value of another will force the calculation of the other attribute. No problem here. Just do not try to set the value of one attribute from another (which is possible, but not advisable :-) ) ... Regards, Mathias |
Re: How many times does a DXL atrribute script run valikund - Wed Jul 22 02:46:58 EDT 2015 Thank you for your in-depth answers, they helped me a lot to see the situation clearer. My question is, that if the DXL attributes have such an erratic behaviour, isn't it better to use an outside script to set the values periodically? Also, when I write my code, should I write to run for each object separately, for example: string s = "New/changed" obj."Attribute" = s Or is it possible/feasible to write it to run for the whole module, ex.: Module m = current Object o = first m for o in m do{} Which approach should I take?
MM is spot on. His comments about read/edit mode are particularly relevant. Getting lots of information while in read-mode is a very important characteristic of CM.
Something doesn't feel right to automatically do this for all your attr-DXL. I'll go out on a limb and say it is ill-advised for new folks; write your attr-DXL with "obj" as the natural context. Don't try the larger module-level context until you are very comfortable with the obj-level. But I have several that do this, primarily those that open other modules; this code lets me close them when done. The natural DXL will either leave these modules open; or if written to open-calculate-close for each object will DRASTICALLY slow you down. BTW, it is required that you use the "entire" loop. Otherwise if you request a value of an object not in the current view you will get no results; and will tend recalculate frequently.
I have several of such maintenance scripts and it is not working out very well. The manage their own "z-xxx" text attributes. Getting them "scheduled" for batch to run at night is awkward at best; now impossible that I'm at a company that requires network login credentials requiring a human being to log in. One of my chores is to convert them back to attr-DXL. One big problem is that users make changes and want to see the results of those changes now; not tomorrow. Some of these scripts are actually project-level and don't lend themselves well to a module-level context. A batch script can calculate a good display for a "Test Plan" and then display it in all the Requirement modules as needed; an attr-DXL will need to calculate that good display for each Req module. I've toyed with the idea of doing both; have a text attribute updated batch nightly and also an attr-DXL. When in Edit mode, the attr-DXL updates the corresponding text attribute as well. Be sure that text attribute's characteristics do not include History/ChangeBars/ChangeDates. I did this once, users complained about the "Save Changes?" prompt when they close the module when they know they didn't change anything. I even tried to save time by getting the attr-DXL to simply display the text attribute value when it knows nothing has changed; this failed as changes were dependent on other modules. I do get carried away.
As MM said there must be no circular references; a chore that is non-trivial to implement. Not that I've ever ever ever ever had circular references (because I am so diligently careful); but DOORS aborts and kills the process without ceremony when you do; doesn't even flick you the finger first. Or so I've heard. When an attr-DXL requests the value of another attr-DXL that 2nd one is run to completion before the 1st picks back up. I actually do this; each one calculating a good display about subordinate linked partners. Link attr-DXL in one module involves requesting the corresponding attr-DXL in the one-level linked partner. I find this vastly easier than the hopeless multi-level recursive Layout analysis code; which I find particularly bewildering although I note other folks have no problem with it. I however get duplicate results when there are duplicate paths to the same object down the chain. On an additional note; attr-DXL that applies to the "module" as well as to "objects" is tricky. IIRC, either I'd check for the [level(obj) == 0] or [obj."Absolute Number" "" == 0] to know to jump to different code to get the results for [mod.attrDXLName = "whatever"]. IIRC, having an "obj" reference to the module level causes some additional problems; avoided by always using the module handle in the calculations.
I find it better to just have Attr-DXL apply either to the module or to objects; not both. -Louie |