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: Dynamic Menu Control
Topic Summary:
Created On: 1-Sep-2003 12:05
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.
 1-Sep-2003 12:05
User is offline View Users Profile Print this message


Tony Goodman

Posts: 1098
Joined: 12-Sep-2002

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
Report this to a Moderator Report this to a Moderator
 3-Sep-2003 01:32
User is offline View Users Profile Print this message


Douglas Zawacki

Posts: 97
Joined: 14-Aug-2003

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

Report this to a Moderator Report this to a Moderator
 3-Sep-2003 09:09
User is offline View Users Profile Print this message


Tony Goodman

Posts: 1098
Joined: 12-Sep-2002

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
Report this to a Moderator Report this to a Moderator
 9-Sep-2003 14:20
User is offline View Users Profile Print this message


Douglas Zawacki

Posts: 97
Joined: 14-Aug-2003

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.
Report this to a Moderator Report this to a Moderator
 19-Sep-2003 21:31
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

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
Report this to a Moderator Report this to a Moderator
 1-Oct-2003 16:16
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

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
Report this to a Moderator Report this to a Moderator
 13-Oct-2003 17:29
User is offline View Users Profile Print this message


Douglas Zawacki

Posts: 97
Joined: 14-Aug-2003

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?

Report this to a Moderator Report this to a Moderator
 14-Oct-2003 16:49
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

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
Report this to a Moderator Report this to a Moderator
 16-Oct-2003 21:37
User is offline View Users Profile Print this message


Alec Witham Crawford

Posts: 24
Joined: 2-Jul-2003

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
Report this to a Moderator Report this to a Moderator
 27-Oct-2003 22:42
User is offline View Users Profile Print this message


Douglas Zawacki

Posts: 97
Joined: 14-Aug-2003

(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.
Report this to a Moderator Report this to a Moderator
 28-Oct-2003 19:09
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

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