Mmc

[Hunterlmc]

I'm looking at developing a fairly extensive application to handle document control (not the source safe type of control) but rather control as in each document will be given a bar code and the program is to record is location and current classification.

Now, becuase the granularity of access to the program, what I'm thinking of is creating and MMC type of interface and then building the different program elements as DLL modules that can be hosted within the MMC framework. I figure that this will simplify future development as anyone wanting to expand the program's functionality will only have to inherit from an existing module or one of a series of base modules to produce new interfaces.

Anyway, I'm looking for a little guidance on producing something like this as it's a level of programming that I have yet to attempt.

Any suggestions, warnings, pitfalls that I should be aware of?

Laurence -

[mstraf]

can you tell us a little bit what kind of file operations will be? Something like browse and editing?
Marco

[Hunterlmc]

The program's only purpose at this point in its development is to track the location of files that have been entered into the system. So, the database will only store "meta" information about each file (i.e. type. location, who currently has the file, etc.). No direct actions against the files is envisioned for this phase of the project (although, I'm trying to talk them into it).

Anyway, the basic operations of the program will be:

Standard User:
Add new document "meta" information to the system.
Edit the document's "meta" information.
Find documents.
Run reports.

Administrator
Everything that a standard user can do.
Administer the system security.

Is that sort of what you were looking for?

[mstraf]

It looks like very different actions can be taken in this application, so you will need a lot of dialogs, each one very different from the other. I guess this is why you have the idea of a MDI "a la" mmc.

Because we are talking about a lot of UI, maybe instead of dll the best is to implement every "action" in a separate userControl. In this way the main app will be only the standard MDI with a menu (and/or toolbar) plus an "empty" child window. According to the action, a new child dialog is created, and the dialog will load a separate userControl. All the userControls must derive from a common interface, so that the dialog does not have to know all the userControl's internal, just the basic.

So, to add a new "action", you have to create a new UserControl based on a common class, and add a new menu item to the main mmc.

Just a thought, as you well know there are infinite ways to implement such a complex app. I use this scheme and it is great. Having different userControl breaks the app nicely into different modules, that can be used like a play of Lego to build other applications.

Marco

[Hunterlmc]

Thanks for the input. I like the idea of using user controls for the different dialogs that a user might want to load.

But, can a user control be created independently of the application and then loaded into the application when the program is run? For example can I create the main application and you create an interface for say updating a document's meta data as a separate dll that can called by the main program?

Or does not make any sense at all?

L-

[mstraf]

absolutely yes, you can load any usercontrols at run time without them be referenced to the app. This is what I do.
All the "common" usercontrols (that is, controls that derive from a known base class) are in a special folder. When the app starts, it scans the folder, loads the controls and tries to get the base class of the control (the base class is the only reference in the main app). If the operation is ok, the module name is read from the base class, and added into the menu. When the user click the menu, the common dialog is open and the corrensponding usercontrol is loaded. In this way it is possible to load as many controls as needed, without ever recompiling the main app. And because the operation is dynamic, controls can be dropped any time in the special folder, without even restarting the main app.

This is an old concept, I did the same in vb6 many years ago, and I do it now in C#.

Marco