Hello,

I'm toying with the idea of loading a MenuStrip (VB.Net 2005)
dynamically based on who is logged into my system.  Every user has
different security settings and I want to customize the main menu
instead of showing all possible options and only enabling/disabling
certain ones.

I have a table that stores the menu item name, parent item (if
applicable), display order, etc. so that I can dynamically load my
menu.  There's also a column called "FormToOpen".  If that particular
field is populated, I obviously want to open the specified form if the
menu item is clicked.  I have a field called 'ReportToOpen'.  If that
particular field is populated, I want to open a SQL Server Report
(utilitizing Reporting Services) when the menu item is selected.  And
lastly, I have a field called "RoutineToCall".  If that field is
populated I want to call the routine.

I suppose I could add all the menu items, place the appropriate code
behind each item, and then remove items from the menu if they're not
applicable.

I have a couple of questions:

1.  Should I scratch what I'm thinking and just go with my second
option above, namely just adding all the items and code at design-time
and just removing unneeded items, or

2.  Go about what I'm trying to do.  And if so, how?  How do I open a
form if the name of the form is stored in a database field.  How do I
call a sub routine if the name of the routine is stored in a database
field? 

Thanks a lot.

Steve

Steve_Bl***@EagleCCI.com wrote:

Show quoteHide quoteYou're asking if you should take an extremely complicated approach to a
situation just for the sake of using a database, rather than dynamically
building a menu based on the privileges the user has.  The choice is
entirely yours - it is you that will have to live with it.  Which one do
you want to maintain?  Which one do you want to look at in 6 months to
make changes to?

Tom

Thanks Tom.  I think the answer to your question really relies on how
complicated it is to program the dynamic menus.  When I say this, I
don't mean actually loading the menu items dynamically.  I suspect
that'll be the easy part.  I mean opening a form, report or calling a
routine if the name of that form, report or routine is stored in a
variable.

i.e.

--Set Connection properties
--Open datareader
--Load Menu and store the appropriate form, report or routine name to
open in the Tag property of the menu item.
--On click of the menu, open the form or report, or call the routine,
that's named in the Tag property.

Depending on how to do this, I don't necessarily agree with you that
the database approach is extremely complicated.  For instance, in
Microsoft Access I would simply do a Docmd.OpenForm (menuitem.Tag) or a
Docmd.OpenReport (menuitem.Tag) or an Eval(menuitem.Tag).  If I
hardcode the entire menu and then remove items that aren't needed for
particular users, every time I add new functionality I'll always have
to remember to update the menu instead of simply adding another record
to a table.  Also, if I'm delivering a new SQL Server report then my
code may not change at all - I just have to add another record to my
table and deliver the report to my clients.  If I hardcode the entire
menu and then remove menu items that aren't needed, I'll have to update
the menu every time I add a report and that means I'll have to
re-deploy the application.

Perhaps this is the way I should have asked these questions:

How can I open a form if the name of the form is stored in a variable?
How can I call a routine if the name of the routine is stored in
variable?

I won't ask about opening a SQL Server report...If I can get those two
questions I can figure out this one easily enough.

Thanks again,

Steve

Steve_Bl***@EagleCCI.com wrote:

Show quoteHide quoteI see.  That definitely changes the scope of the situation.  From the
sound of this, you are building a client-server, rather than a web,
program.
As far as the SqlServer reports, if it is a report provided by
SqlServer, then they can be added as a record.  If you are using Crystal
Reports within the VB.net environment, then that can also be added to
the server, and a report file can actually be stored in the database as
a BLOB.

But to look at what you can do dynamically with MS Access and try to
find the same thing with VB.net, you will frustrate yourself.  Access is
a tigthly bound environment, whereas VB and SqlServer are not.  Visual
FoxPro will allow macro substitution of function and form names, but I
haven't seen anything like that in VB.  You might want to consider that
tool for this particular project.

Based on what you've described though, the approach I would take with
VB.net is to include as a function in a dll, the code for building the
menus.  In the same dll, I would include the dynamic forms.  Because the
menu is built dynamically, the action to take based on a menu selection
can be handled quite easily.  A non-changing function call with the form
name/function name as a parameter will tell the dll what to do.  That
way the interface won't change, which will be good when I update the dll
with another form or function.  Providing the user with an updated dll
file will add the new functionality, provided of course that user has
the appropriate privileges.

In VB.net, a dll is the only way I can find to "dynamically" provide
functionality.  When the app is compiled, it needs to know everything.

I hope this helps.  It sounds like a fun project.

Tom

Thanks again Tom,

I've been reviewing some other posts and I think I'm almost where I
want to be.  I've got this:

When I load my main menu, I'm adding the form name to open into the tag
of the ToolStripMenuItem.  I'm also adding an event handler to the
click of each menu item so that one "master" routine is called
regardless of which menu item is clicked.  Inside my master routine I
check to see if the tag is filled with a form name.  If it is, I call
this routine:

Public Sub OpenForm(prmFormName as string)
   If prmFormName = vbNullString Then
     Exit Sub
   End If

   Dim nextForm As New Form
   Dim nextFormReference As String = String.Concat(MyAssembly & ".",
prmFormName)
   Dim nextFormType As Type = Type.GetType(nextFormReference)

   'nextForm.MdiParent = Me
   nextForm = System.Activator.CreateInstance(nextFormType)
   nextForm.Show()
End Sub

One little glitch that I didn't mention before.  My app is an mdi
application, so all of the these forms I'd like opened need to be
mdichildren of my main form.  As you can see from the above, the line
where I set the form to be a child is commented out.  With this line
commented out as it is, the correct form opens fine, but obviously it's
not an mdichild.  However, the problem is that as soon as I uncomment
that line out, my form doesn't appear at all.  I don't get any errors,
but my form doesn't show up.  I don't know if it's being opened and
then immediately closed or if it's not opening at all.

I also found an alternative routine to do the same thing (please ignore
the naming conventions - I just copied from the Internet and made
slight modifications for now):

    Private Sub OpenForm(ByVal prmFormName As String)
        Dim app As System.Reflection.Assembly =
System.Reflection.Assembly.GetExecutingAssembly()
        Dim dlg As New Form
        dlg = app.CreateInstance("ECCI_THA." & prmFormName)
        'dlg.MdiParent = Me
        dlg.Show()
    End Sub

The only real difference between the two is that the first one uses
System.Activator.CreateInstance and the second uses
System.Reflection.Assembly.GetExecutingAssembly.CreateInstance.
I don't know what the difference is between these two or which is the
preferred method, but this second routine acts exactly as the first one
does - it'll show my form if I don't specify "mdiparent = me", but as
soon as I uncomment out that line my form does not show up.

Incidentally, this routine is of course behind my main form, so "Me" is
valid (and I tested it out by hardcoding a form name and opening it up
as an mdi child - everything worked fine).

Any help would be greatly appreciated.  I think I'm almost there.

Thanks again.

Steve

Well, I've confirmed that when I use

nextForm.MdiParent = Me  (in the first routine)

or

dlg.MdiParent = Me (in the second routine)

the form is not being opened at all (as opposed to being opened and
immediately closed).

Okay, I've done some more testing and I'm really stumped.  I load my
menu as I've said before, and for each ToolStripMenuItem, I add an
event handler so that when a menu item is clicked, it calls my routine:

I won't bore you with the actual code to load the menu - it loads fine
and when I click any menu item my routine gets called just fine.

For testing purposes, I added the following routine and a button on my
form.

Private Sub LoadForm
   Dim frm As New frmTest
   With frmTest
       .MdiParent = Me
       .Left = 0
       .Top = 0
       .Show()
   End With

On the OnClick of my button, I call the above routine.  The form loads
fine.
In my routine that's called from my menu, I call the above routine (and
nothing else).  The form does not load.

I've confirmed that the routine is getting called regardless of whether
I'm hitting the button or selecting a menu item.  So, I'm not sure why
my child form isn't loading via the menu clicks but is loading via the
button click.

Based on this it doesn't seem that my problem has anything to do with
the CreateInstance method I called before. 

Steve

Steve_Bl***@EagleCCI.com wrote:

Show quoteHide quoteI use a similar structure to open a couple of forms, and it works fine. 
But I have one suggestion, only because I seem to recall someone else
bringing this up a while ago: don't use a with block.  Call the methods
with frmTest. before all of them.  Just a worthwhile test - I promise
nothing!

Tom

.NET 1.1 app runs on .NET 2.0?
Accessing a camrea
Warning Text Files Access
Crystal "PrintToPrinter" will not print to Zebra Label Printer... HELP!
Duplicate controls on tab pages
How to convert a regular VB app into a service to run on a Windows 2003 server?
IO.File.AppendText error
vb.net Automation Issues - COM Interop
Crypto Question
FileUpload to SQL