DXL include library stored within DOORS

I am looking for a way to make a DXL library for many modules and many users. I am aware of the "include" feature, but can't reliably get the include file to all users. Users can only reliably login to the DOORS database. Is there a way to store the DXL code in the DOORS database somehow? I am using DOORS 8.1.

I have experimented with eval_ and evalTop_ with some limited success. I have one module which has one object with the DXL library code. Then in each module, I have a module attribute LibCode which sets the DXL code from the library module as the module attribute value. Finally, when I need to make a function call in a Layout DXL, I evalTop_ the value of LibCode.

Problem is, I cannot call functions which are defined in LibCode - I understand that the evalTop_ code is executed after the completion of the entire calling script (see DOORS 9 API manual). I am unable to pass in parameters to the LibCode functions, and I am also unable to use any return values in the calling script.

Is there a way I can make this work? Or is there some other mechanism to generate a DXL code library within DOORS? Thank you for any suggestions.
SystemAdmin - Fri Sep 18 10:14:04 EDT 2009

Re: DXL include library stored within DOORS
SystemAdmin - Fri Sep 18 10:18:47 EDT 2009

Found this:
https://www.ibm.com/developerworks/forums/thread.jspa?messageID=14261922&#14261922

However all solutions include a network drive or include files. Perhaps I am stuck with that!

Re: DXL include library stored within DOORS
llandale - Sun Sep 20 15:05:26 EDT 2009

I made an attempt at auto-sticking some code into top context using evalTop_. It works for future DXL. I believe I could have in fact gotten to work the notion of running eval_Top_ for code, depending on whether it was alread defined. You could run a checkDXL() call on code that uses the top-context stuff, and if it generates DXL errors then you know you need to run the top context stuff. This does not look practical, however.

Yes, you cannot pass non-string parameters to eval_() code. If you want to eval_ something on the 'current module' you will need to pass the full name of the module, and the eval_ code would open that module to get the Module handle.

If you want to include a library file, you can read that file from one attribute, read the program DXL from another, and then
eval_(LibraryDxlCode "\n" ProgramDxlCode).
the ProgramDxlCode would not issue an "#include". The more I think about this the more I like it, since you don't have to pass hokey string parameters to the library. Thinking out loud: perhaps use config files instead of database level module. Advertise a single DXL that folks can download and insert as '-d' command line switch, which reads the base config files and somehow builds the addins and projectaddins menues. Running a DXL will have slow initial load times, so what.

Other folks seem to have some luck auto-downloading DXL from a server to the local client and running it there, but that only improves performance and doesn't really solve the disparat problem. Maybe the clevern notion in the previous paragraph can be used to download DXL from config files, instead of from some common server.

Putting DXL on a server and modifying 'addins' and 'projectaddins' variables works well, so long as all user have access to that \\server. I wrote some layouts and attrDXL that did that for a small Project in a small Database, but as soon as we moved to a more general database it failed due to disparat users etc. The situation was untendable when we started archiving and restoring in contactor databases.
  • Louie