![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Dynamic Menu Control Topic Summary: Created On: 1-Sep-2003 12:05 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
In reply to Douglas Zawacki's question about dynamically customisable menus.
Menu visibility and grey-out behaviour cannot be controlled via the "addins" route. This is achieved by creating menus using the createMenu() and createItem() functions. The first parameter to these can be a user defined callback function that returns menuAvailable, menuAvailableChecked, menuUnavailable or menuInvisible. I am not sure what Telelogic's support policy is if you edit built-in scripts such as formal.dxl, so be careful! ------------------------- Tony Goodman http://www.smartdxl.com |
|
![]() |
|
![]() |
|
Tony,
I am aware of how to use the createMenu() and createItem() functions. But the issue is how do I dynamically create menu items on the menubar of a formal module. If I call createMenu() the error message displayed: <b>function may not be called outside menu/buttonbar configuration</b> Which then leads me to believe that I must call the startConfiguringMenus(DB box | DBE element) function. Now the real question is what is the name of the dialog box for the formal module or even the name of the element for the formal menubar. That information is nowhere to be found. I assume it is hidden in one of the encrypted files. I found where the menu items were being built for the formal modules and I agree completely that I don't want to be adding code to the formal.dxl file. Also note, the file formal.dxl is called only once upon opening doors so attempting to DYNAMICALLY build menus in that file will never work. I should clarify that when I say dynamically build menus I mean I want to be able to build different menu items for different users in different formal modules. If you are able to build a menu on the a formal module menu bar using the createMenu() and createItem() functions. I for one would be extremely grateful if you could share the information because I have yet to figure out the missing piece. Thanks Doug Zawacki doug.zawacki.nodw@statefarm.com |
|
![]() |
|
![]() |
|
Put your menu creation scripts in the doorsHome /lib/dxl/config/formalfiles directory. The files here get run as a formal module is opened. This allows you to execute a test before the menu is created.
for example, a script to create a menu if the user is the Administrator: if (doorsname == "Administrator") { createMenu(alwaysOn, "Admin Menu", null, null) // create items ... end menu } ------------------------- Tony Goodman http://www.smartdxl.com |
|
![]() |
|
![]() |
|
I told Tony I was using DOORS version 5.2 in an email. This was his reply:
Hi Doug, I am using DOORS 6.0. Sorry, I think I gave you the wrong information. I don’t think the formalfiles directory existed in version 5.2. This means that there is no way, that I know of, to actually create menus dynamically. The callback functions given as the first parameter to createMenu() or createItem() do allow dynamic control over the menus. You are correct in stating that all menus are created when DOORS starts, but the callback functions determine whether menus are visible to users according to the context (i.e username or module name etc). This is as good as dynamic menu creation and makes no difference to the way it looks to the user. I’m afraid you are stuck with having to edit formal.dxl. But this could be a small change such as a single #include and a singlew function call to create your menus. Hope this helps regards Doug's Note - I just wanted to point out that formal.dxl is called only once when DOORs is executed. Therefore, using formal.dxl is not an option to create dynamic menus. So, we are back at square one with no answer. I appreciate all of the efforts on this matter. |
|
![]() |
|
![]() |
|
I notice that after opening DOORS explorer, I can change the structure of my addins folders, and the new structure IS incorporated into the NEXT module that I open. This leads me to believe that "formal.dxl" is run whenever you open a module (at least visibly).
So solving your problem with createMenu() etc commands included into formal.dxl seems like a reasonable option. - Louie |
|
![]() |
|
![]() |
|
I've been mulling this over.
I suppose you COULD define pre-module-open trigger that figures out the module and user etc., and redefines the meaning of "addins" via the "setenv" command. Then the menues are built "dynamically" for each module. The main problem, as far as I can tell, is that when you issue "setenv" you actually make a permanant change [] to the doors.ini in v5 [] to the registry in v6/v7. - Louie |
|
![]() |
|
![]() |
|
I absolutely appreciate all of the replies posted. Although, I do have an challenge that I may not have mentioned. I do not want to put the DXL user functions on EACH users PC. Basically, that means that I would like to have a central repository for holding the DXL files. I've decided to just map a network drive that each user will have access to. That makes maintaining the DXL files significantly easier, but makes creating dynamic menus via playing the "renaming folders" game unusable.
But, I must say that your second post regarding changing the reference to the addins folder via a "setenv" sounds promising. I just need to figure out if it's possible. What version of DOORS are you using Louie? |
|
![]() |
|
![]() |
|
Got network deployed DXL Addins working for both v5 and v6. Digressing ... In fact, I've got the SAME DXL working for both (getting v5 DXL to ignore v6 function calls that don't exist was tricky); although some of the v6 DXL makes no sense in v5. ...
Yes, network deployed is MUCH easier than trying to update everyone's client whenever you deploy new DXL. There is nothing tricky about un-dynamic deploying on the network. Build your folder hierarchy, update everyones ini or registry to point to it. Once they are set up, you can add scripts by updating the network (and the *.idx) files, and the next time a user opens a module they get the new script. The trigger "setenv" approach SHOULD work but suspect it will be tough to manage. You will no doubt need another script whose job it is to "set to default the user's Addins/projectaddins variables". The trigger could do wierd things like renaming the addins folders "*.hlp" files to perhaps "*.hlpSuppressed" files, effectively making the folder's DXL ineligible for the menus. Yuuuuuuck. - Louie |
|
![]() |
|
![]() |
|
It's amazing what you learn reading this forum.
By the way, I'm using UNC in the registry (DOORS 7.0), so I don't have to worry about mapped drives. Is there any reason not to do this? Thanks, Alec Edited: 17-Oct-2003 at 13:34 by Alec Witham Crawford |
|
![]() |
|
![]() |
|
(Using DOORS VERSION 5.2)
I would prefer to use UNC but the company doesn't allow it. If you haven't found any problems with using UNC and DOORS, keep it... There are two ways that I am aware of to specify the location of the Addins folder. 1. Via a command line parameter 2. Via the registry setting Neither of these options are optimal for me (Company policies), I am trying to figure out if there is a way to specify the addins folder location via environment variable or some other mechanism that I haven't figured out yet. Typically the Addins folder will be project specific. I probably will post this question separately if I don't get a response here. |
|
![]() |
|
![]() |
|
I'd be surprised that your company policies would prohibit you advertising several desk-top icons with different command line switches, one for each set of addins.
The "setenv" command DOES modify your DOORS.ini (v5) or registry (v6 and v7) PERMANTLY; at least until you issue "setenv" again. For the Addins/ProjectAddins, you will need to set it, then exit DOORS, and load DOORS again to use the new variables. Rats. You can, I suppose, have a series of Icons on your desktop that invoke DOORS in batch mode and sets the variables. Each Icon would adjust the addins menues for the next DOORS run. One Icon would be "I want to use Proj A's scripts", the next "I want to use Proj B's scripts". Yuuuck. The command line switch options look better than this. I'm still a little confused in the difference between, say, variables "DOORSVarName" and "VarName" when dealing with "setenv". Another option would be, perhaps, to define your addins vis-a-vis a mapped drive. Then modify your mapped drive depending on which set of addins you want. - Louie |
|
![]() |
Telelogic DOORS
» DXL Exchange
»
Dynamic Menu Control
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.