![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Client Modifications Topic Summary: Created On: 19-May-2004 15:10 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
We have permission to globally modify the Client Installs by pushing certain files out to all the Clients. My first inclination is to modify "startup.dxl" and insert a
........"#include <\\MainServer\DOORS\Clients\StartupStandard.dxl>" line. We can modify the contents of that file over time to perform different startup chores (keep track of logins, provide warnings yaddy yaddy). However, that would create a situation where DOORS would only work on these clients if they are connected to the network; nobody could use DOORS standalone. Is the following a reasonable alternative: Instead of #including I would insert a piece of code that checked for this MainServer's existence, and if it is then retrieve the StartupStandard.dxl and execute it manually, presumably with the "eval_" command. If the MainServer wasn't connected it would do nothing. Never attempted anything like this. Thoughts? - Louie |
|
![]() |
|
![]() |
|
Having the ability to push files onto clients pretty much removes the need to use mapped drives on servers to hold DXL.
DXL can be pushed onto all the clients by the IT guys, or users can "get" the latest version of scripts from our CM tool. We have an installation whereby availablity of menu options is conditional according to the "type" of the current project or the "type" of the current module. If they are in a module that is configured to use the enhancements, then these enhancements are available, otherwise standard DOORS menu options are all that the user sees. This is a very powerful mechanism that allows us to control exactly what menu options and functionality the user gets. It would be a simple matter, as you say, to check for the presence of a certain file, or the network rather than looking at the current item and then conditionally run DXL in the same manner. The downside to this is that a lot of menu-building files need to be modified to make it work. Also, we hardly ever use the addins folders - you have no control over these. Instead all menus are built using files in the new config folders. The advantage to this is that you can add and remove files as you please without causing problems. ------------------------- Tony Goodman http://www.smartdxl.com |
|
![]() |
|
![]() |
|
sounds as though you need to be able to define login triggers or for the DB server to serve DXL.
(both would be fair CR's) pushing DXL to config/baseWindowMenuCallbacks which does a conDownloadFile to startupfiles (the optionally running it based on the value of DOORSDATA) would be a way of avoiding eval_. A small problem with this is that if you are doing this for several databases, then you now need to keep the DXL declarations unique across all databases - unless you use the base DXL to generate the startup file e.g download files to doorsHome/<port>_<server> generate a startup file (same file name for all DB's) which only #includes files for that <port>@<server> DB Another small problem is that if you change a base window menu customisation then you have to push the change out to all clients - who may or may not be connected at that time. Ross. |
|
![]() |
Telelogic DOORS
» DXL Exchange
»
Client Modifications
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.