I have successfully added a dynamic toolbar based on from suggestions on a prior thread "". When taking these suggestions and applying
them to a menu, you end up with a nested menu item. The menu will place a menuitem wrapper around the ItemsControl. I found this artical that discusses a similar problem.
"Three Ways to Create Dynamic Menus" http://weblogs.asp.net/okloeten/archive/2007/11/14/5149692.aspx
Does anyone have a suggestion on how to avoid the nested menu item?
My ideal world would consist of being able to specify in a module the target parent MenuItem. If it exists, it would attach my menu item to it. If it doesn't, it would create it at that level. This way I can have a dynamic module that can
have it's own sub menu item, and any modules it loads can attach to this sub menu item.
Exit Clinic Reports <<Clinic Module it the parent menu>
Report1 <<Report from sub-module1 loaded from Clinic Module>>
Report2 <<Report from sub-module2 also loade from Clinic Modules>>
The Main parent module should not need to know that Clinic Reports is one of the menuitems.
Does anyone have any other suggestions providing this kind of support, or at least how I can avoid the nested menu item when using an itemcontrol as a menu item?
Jun 20, 2008 at 6:20 AM
Edited Jun 20, 2008 at 6:22 AM
There's a couple of approaches you can try. One using regions (and to get around the border isssue) is to create a specifc Menu Region Adapter. By default we register Region Adapters to handle Content Controls and Item Controls. You can create
a custom one that is implemented specifically for a menu. If you want to support specifying the parent node and such, then create a custom model for your menu items. Have the adapter implementation check that model to retrieve the information it needs for
The second approach is not use regions at all and create a Menu service that wraps the functionality.
I think I'm the kind that likes services, I'll be working towards using a services approach myself.
What I was thinking of was to be able to create a service where modules explain what they want
As an extension to this idea, one module may publish to the menu service that it registered an "extendable" menu by which other modules can locate and add to it (possibly this could be implemented as a child menu service.
- Get the menu service
- Tell the menu service you want to create a menu item under some path "Reports>Clinic Reports"
- Tell the menu service your content for the menu item should be either a FrameworkElement object or an object
- If you specified an object in step #3, then provide a DataTemplate in a merged resource file.
My reasoning for this approach is to allow multiple menus to be present within the UI similar to how IE7 has multiple menus yet they are both the same tree structure. You could then allow a user to alter the layout of the menu through a configuration screen
since it's basically just a data model. For my windows forms CAB apps I do a similar thing but use XML config files to register menu items.
What are your thoughts on doing this? It's just a concept I'd like to try out, but I think it could prove to be very flexible.