Welcome to Telelogic Product Support
  Home Downloads Knowledgebase Case Tracking Licensing Help Telelogic Passport
Telelogic DOORS (steve huntington)
Decrease font size
Increase font size
Topic Title: DXL Attributes - order of execution?
Topic Summary: Determining the order of execution for multiple DXL attributes in a module?
Created On: 30-Aug-2006 16:20
Status: Post and Reply
Linear : Threading : Single : Branch
Search Topic Search Topic
Topic Tools Topic Tools
Quick Reply Quick Reply
Subscribe to this topic Subscribe to this topic
E-mail this topic to someone. E-mail this topic
Bookmark this topic Bookmark this topic
View similar topics View similar topics
View topic in raw text format. Print this topic.
 30-Aug-2006 16:20
User is offline View Users Profile Print this message


Dan Hopping

Posts: 75
Joined: 21-Nov-2002

Is there any way to force (or determine) the order of execution of 'DXL Attributes' within a module?
Hypothetical example: I have three DXL Attributes in a module - DXL3 has input from DXL2 therefore is dependent on DXL2 having already executed which in turn is dependent on DXL1 having already been executed.
As far as I have been able to discover, Attribute DXL execution happens 'behind the scenes' and I have not discovered a way of forcing or (absolutely) determining that order of execution. Seems like knowing the order of execution would be quite useful in a number of instances but only if it is completely deterministic. Has anybody figured this out, or is this just crazy talk?
Thanks,
Dan
Report this to a Moderator Report this to a Moderator
 30-Aug-2006 19:03
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

Don't know. But having attrDXL depend on other attrDXL looks like a big red danger-zone to me.

Consider having a single attrDXL that displays its own value, but also sets the value of the other two text attributes. Thus, DXL-1 is Attr DXL that figures out its own display, and also figures out the display for standard text attrs DXL-2 and DXL-3.

Users can modify the values of DXL-2 and DXL-3 but that would be a waste of time.

Be sure -2 and -3 do NOT affect History, ChangeBars, nor ChangeDates.

- Louie
Report this to a Moderator Report this to a Moderator
 30-Aug-2006 19:26
User is offline View Users Profile Print this message


Dan Hopping

Posts: 75
Joined: 21-Nov-2002

Thank
Report this to a Moderator Report this to a Moderator
 30-Aug-2006 19:44
User is offline View Users Profile Print this message


Dan Hopping

Posts: 75
Joined: 21-Nov-2002

Thanks Louie,
I had tried this earlier but was receiving unexpected results from my DXL.
When I set a value of another attribute it 'appeared' that I wasn't always getting the value I placed in the Text Attribute when I read it into a variable later in the DXL. I got to thinking - maybe the problem was in my data processing and not in the dxl precedence) so I am in the process of writing a test dxl that will show me the definitive results of this process. I'll let you know haw it turns out.
I'd still like to know if anyone has found a deterministic order of DXL processing within modules. Likely it's just 'crazy talk' but if order of execution could be determined it would make life easier eliminating the need for a complex DXLs in a single DXL Attribute.
Dan
Report this to a Moderator Report this to a Moderator
 30-Aug-2006 22:10
User is offline View Users Profile Print this message


Dan Hopping

Posts: 75
Joined: 21-Nov-2002

Louie,
I went back and checked my code and there was a bug in my regular expression parser that made it appear as if the generated attribute values were not being updated every time. So far, in my limited regression testing, I have not seen any errors in the method you suggested. I was able to finish the parser fairly quickly. Thanks for putting me back on the right track.
I guess module level DXL execution precedence is one of those mysteries. Unless I hear from someone else on this subject, I'll lump into my growing DOORs oddities bin (along with another of my favorites - 'Why does the presented order of links invert every time a link module is written to then closed?'
Once again, many thanks for your help,
Dan
Report this to a Moderator Report this to a Moderator
 31-Aug-2006 11:18
User is offline View Users Profile Print this message


Iftakher Uddin

Posts: 56
Joined: 16-Sep-2004

Hi,

Just an idea regarding this topic!

In order to do that we can use a module level opening trigger.

Trigger can update the dxl attribute by force according to the order of execution of 'DXL Attributes'.

Rony
Report this to a Moderator Report this to a Moderator
 31-Aug-2006 16:34
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

I think he's saying is this: the trigger fires after the module opens. Trigger does something like the attached. I suspect there will be a problem if module isn't open exclusive (use "isEdit(mod)") If you don't do anything for Read only modules the code won't run, but the DXL attributes will update on their own in their own order. If so, this approach won't work.

That is, try obj.NameAttr = "" when NameAttr is an Attr DXL and the module is open Read.

- Louie
Report this to a Moderator Report this to a Moderator
 31-Aug-2006 22:17
User is offline View Users Profile Print this message


Dan Hopping

Posts: 75
Joined: 21-Nov-2002

The 'read only' problem turns out to be a bit tricky.
Here is the current scenario:
'MySpecialDXLAttr' is a DXLAttribute that modifies itself based on calculations using another static Attribute (Enumerated type). The problem I am observing is caused when 'MySpecialDXLAttr' also updates another int attribute 'MyIntAttr' as it updates itself. (i.e. writes to the other attribute as Louie suggested)
I can get around the 'read only' access problem without errors by comparing the calculated value (for 'MyIntAttr') to the existing 'MyIntAttr' i.e.

if (calculated value != 'MyIntAttr')
'MyIntAttr' = calculated value

Since nothing changes in Read only mode, this works. But only if all the 'MyIntAttr' attributes were updated the last time the module was opened in Edit mode. I had assumed that the 'MySpecialDXLAttr' would be executed for all objects upon module open . Apparently not so.
This is my current observation: unless every object containing 'MySpecialDXLAttr' is physically displayed on the screen while in Edit mode, the attribute 'MyIntAttr' does not actually get updated by 'MySpecialDXLAttr' (I don't know why). If I scroll thru the module and view each object, everything is updated just fine.
One solution would be to force 'MySpecialDXLAttr' to loop thru all requirements in every object (may have execution speed issues since it's a Big Module).
So... I guess my choices are to update 'MyIntAttr' with a trigger on opening or force 'MySpecialDXLAttr' to loop thru all objects in the module at each object (which doesn't sound like a good approach to me)
Hummmmm.... Think, Think, Think...
Report this to a Moderator Report this to a Moderator
 1-Sep-2006 00:03
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

Mmmmmm.

You could have a pre-close trigger that if the module is in Edit, then it calculates all the values of all these attributes. None of the attributes would be AttrDXL.

You could also have separate AttrDXLs. Instead of having #2 be dependant on the value of #1, have #2 just do the same calculation as #1 and then use it.

Sorry.
Report this to a Moderator Report this to a Moderator
 1-Sep-2006 16:51
User is offline View Users Profile Print this message


Dan Hopping

Posts: 75
Joined: 21-Nov-2002

Louie,

LL>> You could also have separate AttrDXLs. Instead of having #2 be dependant on the value of #1, have #2 just do the same calculation as #1 and then use it

That is how I had always done it in the past, however in this case, I need to access the value of the previous object Attribute#1(which was determined last loop) to complete my processing. Unfortunately, I can't tell what to do with the current object Attribute #2 until I see the previous object Attribute#1. A better way to say it is, I am using Attribute#1 as a persistent 'static variable' to hold an intermediate value for the next object loop.
It may come down to using a pre-close or pre-open trigger. I've had enough trigger related issues (a few DOORs versions ago) to make me trigger shy... Maybe it's time to try again.
Thanks again for your kind assistance
Dan
Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic DOORS forum.
There are currently 1 users logged in.
The most users ever online was 15 on 15-Jan-2009 at 16:36.
There are currently 0 guests browsing this forum, which makes a total of 1 users using this forum.
You have posted 0 messages to this forum. 0 overall.

FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.