![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Why modules open in the background? Topic Summary: Created On: 19-Jun-2008 15:08 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
(please bear with me)
We have a few modules with a standard Layout DXL script on their default views (yes, I know it's bad practice and I'm trying to construct an argument for their removal). I have attached the script below. I make no apologies for it, I inherited it. This script is a reasonably standard one I've seen in these forums to textually represent incoming and outgoing links, e.g. "<-- XYS123 (4.5.6.1.1)" and "--> ABC456 (3.2.1.1.1)". My question surrounds exactly WHAT link/formal modules get opened and under what circumstances when this Layout DXL script is executed. The script loads target modules of outlinks when required, which I presume also opens the appropriate link module. For inlinks, it preloads the source modules (as described somewhere in the DXL Reference Help). If I test this by opening a simple module, the only modules opened (via Manage Open Modules from the Tools menu) are the module itself, plus the two link modules identified in the Linkset list under Module Properties for the module (i.e. those link modules owned by this module). If I scroll down the module to the first object (A) with an outlink, the target formal module (X) (which contains no layout DXL in its default view) is opened to access the target object (B) plus 24 other link modules. I can only assume that X needs to open these link modules for some reason. Only two of the link modules are in the Linkset list under Module Properties for module X, a further two are used in inlinks by the target object B. So where do they other 20 come from? They are ALL relevent to X at some point, but not for the object that is linked. My head starts to hurt at this point. Any help would be much appreciated. |
|
![]() |
|
![]() |
|
There are sever way the modules are open as identified by following lines:
read(otherModName, false) read(specificModName, false) If you want to open them in forground, change false to true |
|
![]() |
|
![]() |
|
I know about the "read" function, and I can see why it would use "false" in these instances as it only wants to get at the ID and number of the object at the other end of the link, noy actually display it.
It doesn't answer WHY so many unconnected link modules are opened. |
|
![]() |
|
![]() |
|
The answer of why a link module is opened is, because a dxl script opens the link module.
Now the dxl script may be your script listed or the dxl script can be any script that is in the default view of a module that is opened. Since a dxl script in a view fires when the default is read -- this can cause a cascade effect. |
|
![]() |
|
![]() |
|
As far as link modules, I had always thought that they were opened automatically by DOORS for any module that has links using them. In other words, if you open a module that has links (either direction?) through link modules X, Y, and Z, DOORS will open X, Y, and Z when you open the formal mod.
Upon some investigation, it turns out that DOORS (8.1, at least) will not load the associated link module until you view whatever object(s) the link that use them reside in. Chris |
|
![]() |
|
![]() |
|
Chris,
this is in DOORS v7.1. However, I have just tried using v8.1 and the same multitude of link modules load up. Ron, if I open module A, which has a link to module B, I would expect the layout DXL as described to load module B in the background to get the ID and number attributes of the linked module B object. I wouldn't expect the layout DXL of the target object in module B to also run unless the module was displayed, which it isn't. I think Chris's comment about all the loading of link modules associated with module B makes sense, as the layout DXL itself doesn't seem to be doing it. |
|
![]() |
Telelogic DOORS
» DXL Exchange
»
Why modules open in the background?
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.