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 Attribute HELP!!!
Topic Summary: DXL Execution and Read Mode
Created On: 27-Nov-2007 20:38
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.
Answer This question was answered by Craig Forant, on Wednesday, November 28, 2007 4:15 PM

Answer:
Your quick responses are always appreciated...

I agree that we are "stretching" the use of Attribute DXL from its intended use, however, I don't think that we will modify this project at this stage of the game.

Therefore, I am left with the annoyance of this error dialog. I will probably just put in a line of code to check module status (if read/share do nothing) as a workaround.

I looked (actually opened my eyes this time) at the reason I was only getting errors when accessing the properties box. It is specifically because the AttrDXL was not in the view. It turns out that I get constant errors (one for every object on the screen) if this attribute DXL is in the view while in read mode.

If it is not in the view, it is being triggered when accessing object properties (which I guess refreshes attrDXL first) My original post was incorrect in stating I had the AttrDXL attribute in the view when opening in read mode.

Thanks for the help.
 27-Nov-2007 20:38
User is offline View Users Profile Print this message


Craig Forant

Posts: 56
Joined: 21-Feb-2005

Should a DXL Attribute execute while viewing the module in Read Mode?

I have a module that uses a DXL Attr to calculate a result, display it, then update another text attribute with a different value based on the result.

The problem we are experiencing is when a user opens the module in read mode, then specifically tries to look at an object's properties (i.e. double clicking the history bar, or right clicking obj > properties), they are imediately greeted with a DXL error stating that DOORS cannot update the text attribute.

This happens regardless of whether the DXL Attr is in view or not. We have switched to standard view to test and still get the errors. We have tried to baseline the module also, thinking it was a history bug, but it did not help.

Any insight would be appreciated.

Thanks.

-Craig

-------------------------
Craig Forant
me@craigforant.com
Report this to a Moderator Report this to a Moderator
 27-Nov-2007 21:09
User is offline View Users Profile Print this message


ron lewis

Posts: 650
Joined: 20-Sep-2004

Craig, If I am reading your message correctly, it appears that you are stretching the intent of attributeDXL when you use it to update another attribute.

The primary intent of attributeDXL is to update the DXL_attribute and not a different attribute.

Attribute_DXL will update itself in read only mode.

Edited: 27-Nov-2007 at 21:11 by ron lewis
Report this to a Moderator Report this to a Moderator
 27-Nov-2007 21:29
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

Yes, perhaps your attr DXL is doing something other than this:
obj.attrDXLName = Results

If the Attr DXL tries to set another attribute you can expect 'no access to modifiy ...' DXL errors, one for every object (when opened in Read mode).

- Louie

While we are here, Attr DXL should really look like this:
string Results = calcualted results
if (null Results)
obj.attrDXLName = " " // use a space instead of null
else obj.attrDXLName = Results

Null value means constantly recalculate, whereas a space will not trigger recalculation.
Report this to a Moderator Report this to a Moderator
 28-Nov-2007 16:15
User is offline View Users Profile Print this message


Craig Forant

Posts: 56
Joined: 21-Feb-2005

Answer Answer
Your quick responses are always appreciated...

I agree that we are "stretching" the use of Attribute DXL from its intended use, however, I don't think that we will modify this project at this stage of the game.

Therefore, I am left with the annoyance of this error dialog. I will probably just put in a line of code to check module status (if read/share do nothing) as a workaround.

I looked (actually opened my eyes this time) at the reason I was only getting errors when accessing the properties box. It is specifically because the AttrDXL was not in the view. It turns out that I get constant errors (one for every object on the screen) if this attribute DXL is in the view while in read mode.

If it is not in the view, it is being triggered when accessing object properties (which I guess refreshes attrDXL first) My original post was incorrect in stating I had the AttrDXL attribute in the view when opening in read mode.

Thanks for the help.

-------------------------
Craig Forant
me@craigforant.com
Report this to a Moderator Report this to a Moderator
 28-Nov-2007 16:36
User is offline View Users Profile Print this message


David Pechacek

Posts: 674
Joined: 5-Dec-2006

You could wrap your DXL attribute code in a if(!isRead(module(obj))) {}

-------------------------
David Pechacek
AAI Services Textron
dpechacek@sc-aaicorp.com
David.Pechacek@gmail.com

Edited: 28-Nov-2007 at 16:37 by David Pechacek
Report this to a Moderator Report this to a Moderator
 30-Nov-2007 03:39
User is offline View Users Profile Print this message


Paul Miller

Posts: 376
Joined: 2-Oct-2002

This topic is rather timely.

I recently had a DXL attribute defined as being a string type and I tried adding the following code lines

string s
s = obj.attrDXLName

The purpose being that I wanted to read the current value of the attribute before it gets recalculated later in the script - having done this, the DOORS client spat the dummy and shut itself down.

Can I assume here that the initial value of obj.attrDXLName prior to the DXL script being executed is completely undefined until it's assigned a value by the executed script? What do I do if I want to know what the current value as part of a conditional routine in the executed script?

-------------------------
Paul Miller
Specification Practices Specialist,
EuroCyber,
Melbourne, Australia.
Mobile: +61 (0)418 135 103
Web Site: http://www.eurocyber.biz
E-mail: miller@eurocyber.biz">pmiller@eurocyber.biz
Report this to a Moderator Report this to a Moderator
 30-Nov-2007 09:40
User is offline View Users Profile Print this message


Tony Goodman

Posts: 1098
Joined: 12-Sep-2002

This one has got me stumped, Paul.

I have tried everything I can think of, but there seems no way that you can access the value of a dxl attribute from within the code that calculates the new value.
As you say, the value is undefined, not even null, until the dxl has run.

While doing this I realised that DXL attributes are not refreshed if the attribute is not currently displayed, even when you select the "Refresh DXL Attributes" menu option.

PS Thanks for introducing me to a new expression "spitting the dummy". Even better than "throwing all the toys out of the pram". :-)

-------------------------
Tony Goodman
http://www.smartdxl.com
Report this to a Moderator Report this to a Moderator
 30-Nov-2007 15:15
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

Ditto.

I tried the attached, put in text attr 'dxlSelfRef'. It 'spat the dummy' every time I tried to display the attr DXL in a column.

When I unlocked and re-opened the module edit, and ran the following from the DXL window, I got no errors.
Object obj
for obj in entire (current Module) do
{ obj."dxlSelfRef" = "0"
}

I then displayed the attr in a column OK; all values were "0". But when I refreshed DXL attributes, it 'spat the dummy' again.

I don't think it makes much sense to self-reference a dxlAttribute since you don't actually have contol over when it refreshes. Perhaps there may be some good use in knowing whether the value was null.

I have some suspition that the value of a DXL attribute is always undefined when you open the module; specifically the values are NOT stored when the module is saved. As I said, "I suspect". Since the value is calculated when accessed, this may explain why the self-reference doesn't work: if it did, DOORS would drop into an infinite loop.

Makes me wonder what would happen if a DXL attribute references another, which references the first, creating a recursion-loop. That would no doubt 'slap the m...' ..err.. 'spat the dummy'.

Lets not do that. Keep AttrDXL (and Layouts) relatively simple.

- Louie
Report this to a Moderator Report this to a Moderator
 3-Dec-2007 04:38
User is offline View Users Profile Print this message


Paul Miller

Posts: 376
Joined: 2-Oct-2002

Originally posted by: Tony Goodman


PS Thanks for introducing me to a new expression "spitting the dummy". Even better than "throwing all the toys out of the pram". :-)


Glad you liked it Tony - it's a fairly common Australian colloquialism.

-------------------------
Paul Miller
Specification Practices Specialist,
EuroCyber,
Melbourne, Australia.
Mobile: +61 (0)418 135 103
Web Site: http://www.eurocyber.biz
E-mail: miller@eurocyber.biz">pmiller@eurocyber.biz
Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic DOORS forum.
There are currently 2 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 2 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.