![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
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 |
![]() |
![]()
|
![]() 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. | |
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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. |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
Telelogic DOORS
» DXL Exchange
»
DXL Attribute HELP!!!
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.