![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Include Statements Topic Summary: Created On: 10-Oct-2005 21:08 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
Hello,
I am in the process of writing a script to be used on a DOORS network of about 350 users, with four seperate servers. I would like this script to be run whenever any other script is run, and so decided to utilize include statements to accomplish this. Unfortunately, it is not feasible to spend the time to locally add the include file on everyone's computer in $DOORSHOME/lib/dxl/...
I am wondering if it is possible to do something like the following:
-Read in the Server Path of the DXL file that is currently running, i.e. store \\DOORS_Server1\DXL_Library\Script_Location as a string SCRIPT_LOCATION
-Parse through the above string to create a new string "\\DOORS_Server1\DXL_LIBRARY\Include_Folder\Include_File.dxl", called INCLUDE_LOCATION. I know the path \Include_Folder\Include_File.dxl will be available on the different servers. (I have already created this code).
-Include the string INCLUDE_LOCATION, so that the .dxl script is run.
My question is how do I get the path name (of the server, not of the local machine) of the script that is being run. Once I use that to create the path of my include file, how do I actually include the file? I have been experiencing some difficulty including strings when I do things like this:
string Path_Name = "\\DOORS_Server1\DXL_LIBRARY\Include_Folder\Include_File.dxl"
#include
|
|
![]() |
|
![]() |
|
Hi Gary,
AFAIK it is not possible to use variables in #include statements. So your idea may not work independently on getting the correct path ![]() Greetings Reik P.S. : Please try to format your message a little bit more - it is very strange to read ------------------------- Evosoft GmbH for Siemens Industry Sector Berlin, Germany |
|
![]() |
|
![]() |
|
Reik, sorry for the formatting complications. It was a little more legible when I was writing the question, but once submitted, all the paragraphs became one. Hopefully it doesn't happen in this response.
As an update, I have been able to answer the first part of my question using the following code:
string Server_Name = getenv("DOORSDATA")
and building up the path name from there. I still haven't been able to find a way to use a string variable in my include statement. Is Reik correct in saying that it is not possible? Any support is appreciated.
If there are no paragraphs visible in this reply, can someone please let me know how to fix that problem?
|
|
![]() |
|
![]() |
|
I suspect you could figure out how to use such an Include featuring a variable by invoking it with the "eval_" command. This will work for you since the invoked DXL has nothing to do with the one invoking it (doesn't pass back data).
But setting that variable is difficult. A DXL cannot deduce the name of the file its running, let alone its path. If you have lots of DXL, how would the users invoke them? If you are updating the "addins" registry entry for these clients which builds an additional DOORS menu item in their modules, then you can piggy back on that. I have a "Modules-Scripts" folder housing the "Modules-Scripts.idx" and ".hlp" files, and the structure of my menu. That folder is in my "Module" folder and that folder is pointed to by the "addins" variable. I also have an "Includes" folder sibling to "Module-Scripts" but it has no *.idx nor *.hlp files; it only has my massive *.inc library. DXL scripts that use the library issue: #include <Includes/Lib-Whatever.inc> and they get to the library OK. The interpreter knows to look for folder "Includes" in the various default locations (home/lib/dxl/addins and then in your Addins path). This works no matter where you deploy the DXL. The only thing you need at the variousn deployed locations is a registry update file that when invoked via a double-click, updates the local client's Addins variable. If you are not using the Addins variable then I don't know how to help you. Well, except that you could store the DXL inside a "configuration file", retrieve it, and then "eval_" it. But then you've got to figure out configuration files. - Louie PS. This relative include strategy works for development, since the Addins variable on MY machine first points to a developmental location, and then to the deployed location. If I'm working on an include file I put it in the Developmental location (in folder /Develop/Includes) and all the DXL running on my machine uses it, instead of the deployed one. |
|
![]() |
Telelogic DOORS
» DXL Exchange
»
Include Statements
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.