4 Replies - 10890 Views - Last Post: 12 October 2012 - 01:29 PM

WinForms FormFactory design question

Posted 12 October 2012 - 12:34 PM

OK, so I have a rather large vb6 project I'm converting and refactoring into VB.Net. It consists of an MDIParent and hundreds of child forms... I'm talking a lot. Each form falls into a category that the company calls "modules" (a reference to the database module it deals with. This is old ass software that was ported to vb6 from an old AIX green-screen system in the late 90's).

The modules are... well... modular. Each install can have 1, 2, or 12 of these modules running. So the design was put in place that each module got its own dll that is dynamically loaded up by the main part of the program. The main part only consisting of the MDIParent and a menu that is constructed from XML (the xml is different dependent on the modules installed).

For each module I've created a FormFactory. When a menu item is selected, it has a 'link-key' in it, just a string that says what should be done when this menu item is selected. I loop through all the factories that are loaded from the modules and find out which one contains said special key. I then construct said WinForm and then show it.

Note some of these forms have multiple states. Most common is a 'read-only' and a 'read-write' state. One allowing for inquiry and the other for "maintenance". They look the same with some buttons or this and that turned on/off.

Now some of these forms can only be opened under special circumstances. For example there is an InventoryMaintenance screen... this uses the InventoryForm which acts as both the InvMaintenance and InvInquiry screens. I can have as many InvInquiry screens open, but only 1 InvMaint screens open.

So in my "FormManager" where I have my FormFactories and do the actual opening based on keys and everything I can do tests before opening the form, and block opening under certain conditions. When doing said blocking some message boxes may be needed to show, or some actions might be taken to make the form eligible to open (like close some other forms or something). Thing is the actual tests needs to be done in each module dll, not the global form manager.

So I need to have some sort of validation method in each module for the FormManager to ask if it's ok to open said form...

And here is where I'd like to ask everyone here for suggestions on how to deal with this.

How would you design this part?

I could just have one big class that case switches key and if it's some special case key I do whatever I need to do, and return some status on if it should block.

I can have a function on each form and ask the form what it thinks before showing this. But it'll either have to be a static method, or need to create a form to ask it (which can be expensive... forms are big).

Replies To: WinForms FormFactory design question

Re: WinForms FormFactory design question

Posted 12 October 2012 - 01:01 PM

Quote

What do you guys think?

I think this is where you break out the emergency bottle of vodka for this one.

My first thought would be to have a custom base class.. that overrides the show/show dialogs and checks on what ever conditions exist so it can appear. That will cut off any sort of odd need for pre-validation by wrapping it in the function itself.

In this sort of odd case I would this yes.. one giant class holding the apps data.. pass that around (or swap it to be a shared class). This would hold states and that jazz while being able to provide an accurate depiction of what is going on.

Things like a boolean if a specific form does open up.. or is closed. That may mitigate some of the running around searching for other forms. I would think of it like a punch-clock system. Individuals come and go interacting with the punch clock but the foreman only needs to look at the cards (aka the boolean variables) to see if so and so is here.. versus finding the worker and asking them directly.

Re: WinForms FormFactory design question

Posted 12 October 2012 - 01:25 PM

Vodka has already been cracked... lol.

Your punch card idea... sounds like that might be helpful. See my keys were functional as well (allowing for parameters in them and the sort), so I wasn't even thinking I could just keep track of what keys (or commands basically) were already open.