![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: When is the code for Layout DXL columns executed? Topic Summary: Created On: 22-Nov-2007 10:09 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() Answer: Layout DXL is only executed when the column containing the DXL code is visible. You can check this by simply creating a column with the following code: print "The current object is # " obj."Absolute Number" "\n" If the column is visible, the output pane of the DXL window will be flushed with messages, and everything will be silent in case it is not visible. Cheers, Peter | |
![]() |
|
According to the Telelogic manual Customizing DOORS with DXL,
<quote> Layout DXL is dynamic in that the DXL code associated with the column is executed for every displayed object whenever there is a change to an object or the screen is refreshed. </quote> I wonder if this code execution also takes place when your current view does not contain any of the Layout DXL columns. In other words: if you have Layout DXL columns, does code execution ALWAYS take place whenever you change an object, whether the Layout DXL columns are visible or not? I hope and would expect the answer to this question is "No" because I'd like to use Layout DXL to show linked objects but only in certain views. However I'm not sure of this. |
|
![]() |
|
![]() |
|
Layout DXL is only executed when the column containing the DXL code is visible. You can check this by simply creating a column with the following code:
print "The current object is # " obj."Absolute Number" "\n" If the column is visible, the output pane of the DXL window will be flushed with messages, and everything will be silent in case it is not visible. Cheers, Peter |
|
![]() |
|
![]() |
|
Peter,
Thanks a lot! Cheers, Pim |
|
![]() |
|
![]() |
|
Layout DXL is also executed when you Manage Views.
This makes removal of views containing bad layout DXL a bit of a chore. You have to ok the errors before you can delete the view. You can prove that layout DXL is not executed for objects that are not visible by doing something reckless like this. Create a new layout DXL column and add the attached code. This code tests for the absolute number of the object for which the dxl is being executed. If the object is object 197, then a deliberate divide by zero causes a run-time error. You only get this error when the particular object is visible. ------------------------- Tony Goodman http://www.smartdxl.com |
|
![]() |
|
![]() |
|
Am including some of the responses in this response.
Layout is executed when the column containing the layout is displayed and the object or the display changes. Basically this means that if there are 3 objects displayed then the layout executes 3 times. If you scroll down one object (losing one object to the top and gaining one object at the bottom), then the layout executes another 3 times (once for each displayed object). Layouts in views that are not displayed are of course not executed. As for Goodman's response: I imagine the layout running when managing the view means that the layout is 'interpreted' but not actually executed; much like if you insert a 'halt' at the top of the DXL and then hit the [Run] button. This would be the same as the 'checkDXL()' perm, as well as the [Check DXL] button on the create layout dxl window. I believe that it doesn't 'execute' for each displayed object in this case; it just interprets it once. Layouts apply to a column and must be saved in a view. Notice that if you delete the view containing the layout then HEY!! the layout is deleted. Layouts (and Attr-DXL) that feature #include statements will require that all users have access to the specified file. That's unlikely even in small deployments and not reasonably possible in large or distributed deployments. Thus, you need to avoid #include statements in layouts. Ditto for 'readFile' commands. Layouts featuring link traversal are nightmares for the GUI, since they execute so darn frequently. Attr-DXL seems superior to LayoutDXL, except that it requires Edit access to the module to create such an attribute. Attr-DXL does NOT recacluate ever time an object is displayed and thus have a huge performance improvement over layouts. However, to prevent constant recalculation of Attr-DXL you need something like this at the bottom: string Results = results of the Attr-DXL if (null Results) obj.attrDXLName = " " // Use a space instead of null else obj.attrDXLName = Results - Louie |
|
![]() |
|
![]() |
|
These are some valuable additions, Louie.
I agree that Layout DXL can be slow. What I did is use the Layout DXL only in specific views which sometimes are requested by the user, such as which requirements on the higher level are covered by the current requirements or which requirements on the lower level cover the current requirements. (In my opinion different link modules per formal module are perfectly acceptable AND everything should be automatically generated, so I don't want to use simple filters). After reading your post I DID replace all my #include's with pure code. Like so: const string DXL_SATISFIED_BY_ID = "Link lnk\n" //- "LinkRef lref\n" //- "string srcModName\n" //- "Object srcObj\n" //- "string satisfiesLinkModule = fullName(current Module) \" Satisfies\"\n" //- "for lref in obj <- satisfiesLinkModule do {\n" //- "srcModName = fullName source(lref)\n" //- "if (!open module(srcModName)) {\n" //- "read(srcModName, false)\n" //- "}\n" //- "}\n" //- "for lnk in obj <- satisfiesLinkModule do {\n" //- "srcObj = source(lnk)\n" //- "display(identifier(srcObj))\n" //- "}\n" That at least doesn't look TOO bad thanks to the //- . |
|
![]() |
|
![]() |
|
Not sure what to think about the format of your DXL_SATISFIED_BY_ID variable; it appears you have a DXL whose job it is to create a column that features that layout.
If so, you may want this code: string ErrMess = checkDXL(DXL_SATISFIED_BY_ID) if (!null ErrMess) { infoBox(ErrMess) halt } That will prevent you from posting DXL in the column that doesn't even interpret. you can populate DXL_SATISFIED_BY_ID variable two other ways: [1] Keep the source of the layout on your computer and use DXL_SATISFIED_BY_ID = readFile("c:/Folders/MyDXL.dxl"). That allows you to code MyDXL.dxl naturally. Use natural EOLs instead of all that concatenation. See attached. Notice the leading " on each line is deleted, as are "/n" //- last 7-8 characters at the end of each line. - Louie |
|
![]() |
|
![]() |
|
Hi Louie,
you mentioned on your post on date 26-Nov-2007: "...Thus, you need to avoid #include statements in layouts...." Were also trying to keep our DXL-Layout-Code on a Network-Drive where every user has acces. Using the readFile() and eval_() functions (so we can check the existens or acces of the dxl-file) we have no idea how to get a handle to the "current Object" of each line: "obj". Question: - Is there any possibility to ship "Current Object " "obj" by a parameter? - Is there another way to keep the DXL-Code on a Network-Drive and call it from the Layout-DXL-Column? Thanks, Martin |
|
![]() |
|
![]() |
|
You don't need to pass the current object.
obj is automatically set from the context in which the layout DXL is running. so you can assume that obj is always set correctly to the correct object. In fact you should make sure that you always use "obj" and not "current Object". The distinction can be demonstrated by creatign a layout DXL column with the following code: display identifier(obj) display identifier(current Object) The output from each line will only be the same for one object - the currently selected object. ------------------------- Tony Goodman Smart DXL limited www.smartdxl.com |
|
![]() |
|
![]() |
|
I always use obj. The problem is that I get an error using the eval_() function to run the Code. Using #include I don“t get the error.
Try following: 1. Create a file (Test.dxl) with the Code: display identifier (obj) 2. Write on the Edit Layout DXL -Window: #include "..../Test.dxl" 3. Result: OK ----------------------------------------------- 1. Create a file (Test.dxl) with the Code: display identifier (obj) 2. Write on the Edit Layout DXL-Window: eval_( " #include \".../Test.dxl\" ") 3. Result: DXL output: incorrect arguments for function(identifier) WHY??? |
|
![]() |
|
![]() |
|
Any code called via the eval_ perm is run in its own context, i.e. it does not know about the context in which eval_ itself is called.
On the contrary, "include" statements just, well, include the code from the named file. In your first example, using include just means that the code written in the Test.dxl is executed in the layout DXL context. In the second example, using eval_, however, the code from Test.dxl "does not know" that eval_ itself was called in a layout DXL column, and "obj" is an unknown variable. AFAIK, there is only one ugly way to get variables "inside" the code executed via eval_, and that would be by using global variables defined at system startup. That's just an idea, I have never used it or seen code where this was used. Cheers, Peter |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.