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: Use of #include
Topic Summary:
Created On: 15-Feb-2004 18:59
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.
 15-Feb-2004 18:59
User is offline View Users Profile Print this message


Stian Aase

Posts: 11
Joined: 13-Nov-2003

My DXL is invoked from external software (using Automation), but I am confused bout correct use of #include.

Placing my scripts in /addins/user doesn't seem to be enough - so far it seems the only way to successfully have the interpretor find my code is to go #include "/addins/user/myfile.dxl". (Why does that work anyway using v. 7.0 on my Win32 platform - should I not have to use double backslash, or is it another example of incomplete doc?)

Does "The One Right And Robust Way To Include DXL Files" exist? From the doc, I get the impression that placing code in /addins/user does the trick - meaning the interpretor should find it from #include "myfile.dxl"?

----------------------------
Stian Aase
Computas AS, Norway
Report this to a Moderator Report this to a Moderator
 16-Feb-2004 19:28
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

Finding your includes is NOT quite the same as finding your DXL. Includes are two levels higher since looking for module level addins means looking for "/addins" and then looking for well formed FOLDERS containing well-formed addins *.dxl files (in this case "/user"). I never use the local "user" so I rename the folder to "user-old" to suppress that Module menu item.

If you put DXL in the $home/lib/dxl/addins folder you'll need to specify an "addins/" in your include statement: File $home/lib/dxl/addins/MyInclude.inc can be accessed with #include <Addins/MyInclude.inc>.

Its confusing even for me after all these years. Figure 5-7 trial-and-errors before you get it right.

Note that the above $home/lib/dxl is searched even if you also have an "addins" registry command. In fact, its searched BEFORE the "addins" command, so if you have more than one deployed include file with the same name it will find it locally before externally.

I'd be tempted to create a new folder $home/lib/dxl/Includes/ to house your Include files, and use #include <Includes/MyInclude.inc> to get at them. This has the rather big benefit that you can later rehost the includes on the network, perhaps in //MyNetwork/DXL-Addins/Includes, specify //MyNetwork/DXL-Addins in your "addins" registry, and all your DXL will STILL work since the new Includes folder is still correct relative to your addins path. If you also create a //MyNetwork/DXL-Addins/Module-Scripts/ etc menu you'll get Module Addins deployed from the network.

If you DO rehost be sure to remove the local Includes folder.

The Addins command I use has 5 separated entries; one for my own local DXL, one to handle the v5/v6/v7 differences in DXL, one to find the includes, one to find the module addins, and one to find the project addins. That took about 40 trial-and-errors to get right; I hate it when that happens.

Once you get it to work be sure to archive the folder and Registry commands to make sure you don't forget how later.

- Louie
Report this to a Moderator Report this to a Moderator
 17-Feb-2004 16:43
User is offline View Users Profile Print this message


Douglas Zawacki

Posts: 97
Joined: 14-Aug-2003

Let's assume I have a folder structure as follows:

DOORS/mystuff
DOORS/mystuff/lib
DOORS/mystuff/menus
DOORs/mystuff/menus/menu1
DOORS/mystuff/menus/menu2

I have setup a DOORS icon with the -addins command line parameter.
(ie. -addins "c:/doors/mystuff/menus")

Setting addins to the root of the menu folder allows the menus to be displayed in the formal module menus. DOORS also looks at the standard addins path of $DOORSHOME/lib/dxl/addins/

All other DXL code can then do an include relative to the ROOT ("c:/doors/mystuff/menus")

With the addins path set I can now do #include <../lib/mydxl.dxl>

I use this feature to also do #include on Attribute and Layout DXL code as well.

It seems to work well for me. Hope it helps.
Report this to a Moderator Report this to a Moderator
 18-Feb-2004 14:36
User is offline View Users Profile Print this message


Douglas Zawacki

Posts: 97
Joined: 14-Aug-2003

Roger,

I think the answer is to use relative includes.

I would set the DOORSADDINS path to have the same folder structure starting from the "addins" folder.

Then all includes should be relative ie. #include <addins/lib/mystuff.dxl>
or even something like #include <../support/whatever.dxl>

To share the dxl files with others, place all the dxl on a network drive and have the DOORSADDINS path point there.


Edited: 18-Feb-2004 at 14:38 by Douglas Zawacki
Report this to a Moderator Report this to a Moderator
 18-Feb-2004 15:24
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

That is a curious feature, never noticed that before. But the solution is simple:
[] Create folder ../lib/dxl/Includes/
[] Create folder //MyNetwork/DXL-Addins/Addins-Mod/Includes, (contains no IDX file)
//MyNetwork/DXL-Addins/Addins-Mod/ModScripts (contains an IDX file)
[] set variable "addins = //MyNetwork/DXL-Addins/Addins-Mod

In your DXL, insert "#include <Includes/MyInclude.inc>".

Now when you run this DXL it will first look for "MyIncludes.inc" on your local C drive, and if it doesn't find it look for it on the network. Thus, /lib/dxl/Includes is when you are testing your includes.

I actually use this where-to-look-first scheme to handle DXL that is different in v5 and v6.

-Louie
Report this to a Moderator Report this to a Moderator
 18-Feb-2004 15:50
User is offline View Users Profile Print this message


Douglas Zawacki

Posts: 97
Joined: 14-Aug-2003

I extracted the zip file to the standard $DOORSHOME/lib/dxl/addins. Now I have a folder with the three files in there with the path of $DOORSHOME/lib/dxl/addins/helloworld.

I open a formal module and the menu works.

I extracted the zip file to the DOORSADDINS path (I have defined as n:\mystuff\menu). Now I have a folder with the three files in there with the path of n:/mystuff/menu/addins/helloworld.

I open up a formal module and (as expected) I see two menu headings with hello world on them and they both work. Because your include was relative. So, what you sent me works fine for me. I suspect that there is still a missing piece to the puzzle.
Report this to a Moderator Report this to a Moderator
 18-Feb-2004 17:30
User is offline View Users Profile Print this message


Douglas Zawacki

Posts: 97
Joined: 14-Aug-2003

AH, there it is...yes I see your point now Roger.

I fixed the problem by changing my -addins path to look as follows:

-addins c:/program files/doors/lib/dxl/addins;n:/doors/mymenu/addins

By forcing everyone to have the -addins path then the extract process would be the only challenge.

I see your problem but the only solution I can think of is to force an addins path. I tested this out on my pc and it works with both paths set to the -addins. I hope this is a viable solution for you.

NOTE: I'm sure you realize that you can change the addins path either in the ini file (DOORS 5.2) or the registry (DOORS 7.0) or via the command line using the "-addins" parameter.

Report this to a Moderator Report this to a Moderator
 18-Feb-2004 17:56
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

Have all your include statements be of the form: #include <Includes/ ...inc>. Build an /Includes folder with all your included files. Put TWO identical copies of this folding in your zip; one at the "root" level (for deployment in lib/dxl/) and one under the "ModAddins" folder (for deployment in DOORSADDINS/ModAddins/). If you don't like two copies, you can instruct the loca C drive deployers that thay have to MOVE the /Includes folder one level up.

Anway, I've been struggling with deloying DXL for years.


I've tried pushing DXL to everyone's C drive but its a nightmare to manage, especially when some insist that "what I've got works, don't update it". The best solution so far is to deploy them on a Network and update everyone's DOORS.ini (v5) or Registry (v6/v7) with the addins (projectaddins, attributeaddins, layoutaddins) commands. I've got a standard *.reg files on the networks that they can double click on to update their registry. We CAN update the registry even if they don't have load-privaleges on their own machines, but updating the "HKEY_CURRENT_USER" area rather than the "HKEY_LOCAL_MACHINE" area.

When on the server I can deploy new DXL, updates, or library updates at will. I also update to different servers in different divisions without any modification to the DXL itself.

The real problem is for Layouts and Attr DXL, since they use the $include files but they MAY be accessed by people who don't have access or don't have their "addins" point to the includes. These folks get numerous DXL errors (if they load a view with one of my Layouts in it); and I don't know what to do about that (noError() and lastError() commands didn't work with #include statements or other interpretation errors, only on time errors). This problem compounds itself when modules are restored in away databases. Making the Attr and Layout DXL include-file-less looks pretty tough, but may be my only real option.

Another thread discusses building the module/project menu's with "createItem" commands, but that requires each User to modify a couple of their installed DXL (formal.dxl) to #include some network DXL that does the work; and it doesn't solve the include file problem.

Another Option I've been toying with is to write a "DeployDXL.dxl" utility. It finds all the Deployed DXL and finds where the /Includes are located, and then opens ALL the *.dxl files and modifies their #include statements to include the full path and name of the actual Include files.

Another option is to again write such a utility, but instead of modifying the #include statement I would actually open the Includes and insert the code right into the *.dxl file itself. Thus, deployed DXL uses no #include statements. We've got a serious proprietary issue with that, however. I thought about combining this option with your "QLSInc" q-encrypt utility; but then we cannot put the DXL in the Module Menu without dummy *.dxl that includes the actual code; and that pretty much defeats the entire purpose.

I conclude there is no great way to deploy massive DXL.

- Louie
Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic DOORS forum.
There are currently 0 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 0 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.