![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: install dxl script ? Topic Summary: Created On: 17-Jan-2008 02:56 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|||
hi,all.
I write some dxl script in my own computer.I want to use these dxl script in another computer. On way is copy these dxl script into the directory of another computer. Has any other way. eg. collect tht dxl script into a package ,then install the package in another computer. How ??? Thanks. |
|||
![]() |
|||
![]() |
|||
Just move the dxl file into the addins/user directory of their DOORS install.
------------------------- David Pechacek AAI Services Textron dpechacek@sc-aaicorp.com David.Pechacek@gmail.com |
|||
![]() |
|||
![]() |
|||
You can move DXL scripts around but that creates a CM nightmare. I don't think you can use 'shortcuts' to redirect to your partner's CM DXL.
You can use the 'addins' environment variable to direct the local DOORS windows to use build menus that run DXL from other folks computers, usually network servers. That is, you put the CM controlled DXL on a server and tell everyone to update their 'addins' variable to point to it. Setting up the DXL is a little tricky as is setting up the folder hierarchy required to support them, as is definiing the addins (and projectaddins) variables. Instead, you could realistically put a skeleton DXL on your computer that #include's your partner's DXL. Then when your partner updates her DXL, you get ..err.. you use the new version next time you run it. - Louie |
|||
![]() |
|||
![]() |
|||
I have found that it easiest to put shared scripts on a networked location and manage access using the DOORS registry settings.
I have attached a DXL script I use to set the DOORS registry values; seems to work even if you don't have access to run regEdit (or similar). The script displays the current value of your DOORS registry variables (some of them), and lets you change them (if you want to). The script has a number of constants for default locations which, if you edit the script, you can set up the registry on a machine with just one click. The script works for me, and I have used in on v7.1 and v8.1. Note that after you run the script, and your registry has changed, you need to restart DOORS for the changes to take affect. Hope this helps, Regards Michael.
|
|||
![]() |
|||
![]() |
|||
I user Registry Update files. I deploy these files on the networks along with the DXL. I advertise that if folks want to use the DXL, they navigate to the network and double click on the file.
Recent restrictions by IT departments deny 'Admin' rights for users to their machines, which denies the 'HKEY-LOCAL-MACHINE' area of the registry but still allowing modification of the 'HKEY-CURRENT-USER' area. This means that now, users can 'deploy' addins for themselves on their machines but cannot deploy them for all users of their machines. Anyway, the following lines should be placed in a *.reg file, perhaps 'DeployAddins.reg', and users would double click on it. Note: the first line 'REGEDIT4' is a very old RegEdit version string and is recognized by all currently versions of that program. - Louie REGEDIT4 // Use NGC Deployed DOORS DXL addins on the server MyServer... // for only the current user of this Client machine. // Should create Project-Scripts and Module-Scripts menus. [HKEY_CURRENT_USER\Software\Telelogic\DOORS\8.1\Config] "addins" ="\\\\MyServer\\DXL-v8\\Module;\\\\MyServer\\DXL-v8\\Project" "attributeaddins" ="\\\\MyServer\\DXL-v8\\Module\\AttrLayout-Stuff\\AttrDXLs" "layoutaddins" ="\\\\MyServer\\DXL-v8\\Module\\AttrLayout-Stuff\\Layout" "projectaddins" ="\\\\MyServer\\DXL-v8\\Project" "defopenmode" ="READ_ONLY" "defopenlinkmode" ="READ_ONLY" |
|||
![]() |
|||
![]() |
|||
Interesting script Michael. Those registry keys don't appear to exist on my machine. I'm assuming that once created, they work?
Instead of doing what you're doing, I've written a script to pull tools off a network share that contains a mock addins directory. Tools are pulled on an as needed basis. So some users get some tools and others get other tools. ------------------------- David Pechacek AAI Services Textron dpechacek@sc-aaicorp.com David.Pechacek@gmail.com Edited: 18-Jan-2008 at 15:01 by David Pechacek |
|||
![]() |
|||
![]() |
|||
David,
The keys weren't in my registry either, but they are defined in DOORS so work. I get the same functionality with the registry settings method. The 'projectaddins' key specifies the location for scripts that appear on the DOORS explorer menu, while the 'addins' key applies to the module level menus. The 'addins' key also specifies a search path for include statements in scripts. The dxl/attribute layout keys specify locations for when you select the browse option when specifying a dxl or layout attribute script. By specifying user access to the script locations determines the menus that show up for a particular user. E.g. if a user has no access to a particular directory of scripts or individual scripts then those scripts will not show up on that user's DOORS menu. This all assumes that you have set up scripts directories as per DOORS standard. We have scripts located on a server on the other side of the country, have set the registry settings as described (same for everyone), and all users get access to the scripts that they have access to. No pulling off scripts temporarily, and menus on everyone's machines set simply by changing access rights to the scripts on the server (using access groups makes it simple). I can see that what your script does would work but it's much easier to set up your environment once (set and forget). This is simple for users that run scripts from the DOORS menu but don't know (or don't want to know) how to browse to scripts and run them. Regards, Michael. |
|||
![]() |
|||
![]() |
|||
The Registry method, sadly, has a serious drawback: if the server is 'far away' on the network and you have lots of addins folders and scripts, it takes significantly longer to open modules. This is because each time a module is opened the network folders are browsed and all the *.dxl files therein opened and consulted, in order to build the menues.
We are at a large company and are forced to deploy scripts in multiple locations, hoping that all DOORS users are 'close' to at least one such location, and point their client's registries there. From a CM perspective its not so bad since we just copy new deployed folders over each of the deployed locations. We access another company's DOORS via Citrix. I've cleverly manipulated my HKEY_CURRENT_USER area of the Registry in Citrix to point back to DXL addins back on my client. It takes 45 extra seconds to open a module since the client is 'far away' from Citrix, oh well. IIRC, a server is 'far away' if its 'ping' time is >20ms. I've always entertained a nagging thought of 'deploying' DXL via DXL 'configuration files', where scripts are stored on the server and a clever login trigger updates the local client whenever new scripts are deployed. I've also always entertained the notion of 'deploying' DXL, not via registry 'addins', but rather via manipulation of the 'formal.dxl' file and building the menus with direct menu commands. I presume that it would be faster execution than the addins method even though the files themselves are on the same place on the network. - Louie |
|||
![]() |
|||
![]() |
|||
Louie,
I can see that there are pros and cons either way. I'll close by saying (jokingly)... Setting up registry to central server......60 seconds. Extra time to load a 'far away' module.......45 seconds. Knowing that you always have access to the correct version of scripts........Priceless. For everything else there's CM. Michael. |
|||
![]() |
Telelogic DOORS
» DXL Exchange
»
install dxl script ?
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.