Best practice for coding two similar forms?

[John Heitmuller.]

Hi, I am a C/C++/C# programmer that has inherited a HUGE VB.Net
application with several VB forms. I am a mediocre VB programmer.
Two separate companies are now going to be using the application.
Most of the forms are fine for both companies. A few of the forms
require significant modification for one company to use the. Of the
forms that I do need to modify about 75% of the VB.Net code behind the
new form and the old form will be the same.

If I was coding this in C#/C++ I'd handle it this way.

· Create and #include file with the common code for both forms. We'll
call this form1_common_code.inc.
· Create a separate source file for each form with the code that was
unique to that form. We'll call these form1_a.vb and form1_b.vb.
· I would then have form1_a.vb and form1_b.vb include
form1_common_code.inc.

From what I've been able to find in the VB documentation VB does not

support this approach. The recommended approach seems to be to create
a custom control with the common code and have each form and have each
form use the custom control. I do not think that a custom control
will work here. The nature of changes that I will need to make just
do not fit that approach. I'm trying to avoid created a completely
separate form for each company, but that does seem to be the simplest
approach in the short run, with obvious problems in the long run.

Does anybody have any advice on a good approach to this before I
commit myself to maintaining completely separate copies of the form
for each company?

Thanks,
John

 

[Guest]

how about creating a form that has all the common code. then, when you need a
specific form for a specific company, create a new form that inherits from
the common code form. this will give the common code to whatever form
inherits it, plus you can add new functionality. hope this helps

 

[Miro]

Im still a vb beginner, but lets say formA is your main form,
and fromB is going to be the custom form.

If formA gets a "checkbox added" later on, will companyB expect that
same checkbox to appear somewhere on formB ? or do they expect their
customization / formB to remain stagnant until they request changes?

Just the way I am teaching myself / seeing how vb works, in my mind -
simple is easier, and creating 2 separate forms will be easier hitting
functions - perhaps in a module / or a class you can instantiate.
-But thats a pure beginner talking.

I think if you try to incorporate the 2 forms together, you might run
into a problem later on in life if CompanyB wants more custom stuff
added to formB that CompanyA does not want / or may not want to see on
FormA.

I have worked on big company's in my past/still do ( but currently in a
different language ) but the company does not want any "screens" to
change unless they specify. This is because they have all their
internal documentation they write - and would have to re-write each time
we would choose to add functionality.

Do you know what each customers requirements are regarding "changes" to
the screens when 1 of them want something and the other does not?

That might help people ( with way more experience ) than me...answer
your question about which way to go.

Miro

 

[Cor Ligthert[MVP]]

John,

Beside unsave code has C# nothing that VB.Net not has (In the oposite
direction there is more).

The way in C# for this is to create a base class (a form) that you inherit.
This is exactly the same with VB.Net and C++ for .Net.

Cor