Ok. Its been a while since the course and I think I may have forgotten more than I learnt !!

Just looking for a few pointers at this stage. I want to set up a menu type system where there will be say 50 forms, and different users that log in to the app should only be able to run specifc forms.. e.g User Joe might be able to run FormA, FormD and FormG whereas Steve may run Forma, FormB and FormX. (The users would also be in Groups)

Which control would be the most appropriate to use for this type of access. Ideally, when Joe logs in he should only see FormA, FormD and FormG.

In Foxpro, I used GenMenux for this ,but dont necessarily want to use a Menu if some other control is more appropriate or more 'in fashion' these days

Well, this is something that you will need to handle manually in a table where you have all your groups and forms assigned.



I am currently working with the Infragistic UltraToolbarManager which mimics the Office 2007 UI and allow you to create as many ToolItems as you want, then create several Tabs for your grouping and assign any Toolitem to any Tabs programmatically. This control will allow you to have your forms definition in a Toolitem, and then you can have this information in a table and when the user login read this table and assign the ToolItems to the corresponding Tab.



Keep in mind that this control allows you to set Visible any object programmatically giving you the flexibility you need. Of course there are other vendors with similar tools other than Infragistics.

Edhy Rijo

I think the first thing is to do as Edhy suggested and have some meta data driven way to manage this, likely via a table(s) to manage the association of roles/groups/users to forms. You could also use a configuration file or a web service or ... Tables are easiest.



Then you'd use BOs to access this data. Then you'd need to manage some UI elements. Edhy suggested an Ingragistics tool, but there are many choices, including standard .NET or SF tools. Here are some suggestions:



1. Create menu with all items shown, then hide the ones that the user doesn't have access to. This might seem the easiest, but can be a bit challenging as you have to do lots of looks up.

2. Load a combo in a menu/toolstrip with the list of forms they can open. This is easy, but not very friendly.

3. Use a navigation panel on the left of your main form (assuming MDI here), and load either a SF Listbox or a SF ListView. This is even easier, as you can just use the standard SF list population methods to load the list of forms for a user.

4. Use a SF ThemedLinkMenu in the panel on the left. This looks slick and has some nice UI elements. You'd have to manage this more manually. I.e. get the data, then create the ThemedLinkMenuItems. However, there are samples of how to do this in the StrataFlix sample. In that case, they are using the ThemedLinkMenu for actions (like edit, search, delete), but the concept is the same. Also, I believe they sub class the ThemedLinkMenuItems, so that might be something you'd do also, such that each ThemedLinkMenuItem would know how to actually open the form.

5. Create a switchboard form, that has a list of forms they can use. Here you could use just about anything, including the listbox, listview, a tree control, create a list of link labels. This can be nice to provide context for occasional users or beginners, but can get old for experienced users, who'd appreciate faster navigation.



Then there are all of the other third party options, like Edhy suggested. Many of these will have Office 2007 like ribbon options or Outlook like options.



I hope this sparks some ideas and/or conversation on the topic for you!

Hi Edhy and Greg.. thanks for your very informative replies.

I've narrowed down the parameters for the menu type control I would like to use :

1. Is a SF control (dont want to at this stage get 3rd party controls and also want to play around with SF controls)

2. Is 'easy' to set up at this stage .. does not have to be that pretty (to get familiar with stuff)

3. Comes close to the type of Outlook 2007 functionality...

Would welcome suggestions

We take a different approach and use only SF controls (no surprise there, right? ).  We use a ThemedLinkMenu for most of our menus.  You can add, hide, etc.  However, off of one of our links in a ThemedLinkmenu, we use the Popup class that comes with SF (Has to be implemented in code) which allows you to hose any other control as a popup (like a combo drop down, menus, etc.).  We have a customizable section that is retained by logged-in user that let's them pick the most common things that they go into.  You could take a similar approach as well for menus that wil be dynamic.  But like the guys said, you are going to have to create your application environment and then using meta-data would be the best way to go (data that aides in the display of which menus [or links] will appear).

Just another idea

Note: In the image above, the links on the left and right are ThemedLinkMenus (SF Controls).

One other example I thought I would share is our "Main" application button menu.  When you click our Application Button, it pops down (using the Popup class again) another user control that has a ThemedLinkMenu on the left that when selected shows an SF ThemedContextMenu (all of which can be shown, hidden, programmatically added, removed, etc.).

Just thought this might be another idea.

First, nice examples! I'm getting some great ideas here, even though Gerard asked the question!



Second, I think Trent was looking over my shoulder when he typed this:

LOL...I meant that to be "host"

Like Edhy I use the Infragistics "ribbon" but instead of implementing form access using tables, I use the SF security system to determine form access. Each form has a permission and any menu/toolbar item which calls a form is able to work out the correct security permission to check. When the ribbon loads it checks permissions on all toolbar items and hides the items the user is not allowed to see. This could also mean that a group or tab is also hidden if the user isn't allowed to see any items within the group or tab.

I appreciate you don't want to use a third party control but the SF security system is very easy to use.

Hi Aaron,

This approach looks to be pretty good since the RBS will host all Menu Items. I have a couple of questions about your approach:

1) In order for you to hide a tab or group, in the RBS are you creating a Permission for each Tab and also each form?

2) At design, are you assigning the ToolItems to the Tabs?

3) At runtime, are you looping through the security RBS records to load the ToolItems, or are you looping all the ribbon Tabs and checking the security for each to load the ToolItems?

Edhy Rijo