How to divide a big Project

[Andrzejek]

I have a VB 6 program with 176 forms,15 modules and growing… It is based on ORACLE database. All of it creates one EXE (size - 33, 156 KB).
I know, it’s a lot, that’s why I have this question.

What would be a good way to divide it into smaller pieces?

I know I can have multiple Projects in my VB, but the problem I see is: we have one connection to DB and we stay connected while in the program, and close the connection on Exit. Also, some Forms are accessible from several places (other Forms) and Modules are accessible from many Forms as well (obviously)

Can I have several Projects in VB that use (access) the same Form and/or Module so I don’t have to repeat them in every Project?

Some good ideas would be welcome.

---- Andy

 

[vladk]

Andrzejek,
Yes, absolutely. I routinely utilize the same module(s), located in some common folder, in several independent projects. The projects share such modules or forms.
vladk

 

[Golom]

I agree with vladk ... but with a word of caution. Once you place a form (for example) in a common location and reuse it in several different projects, note that any change that you make to it will appear in EVERY project where the form is used.

It's probably best to start with modules or classes that don't (usually) have a visible interface. For things that do, you want to be sure that exactly the same visual interface is appropriate for every project that uses the component.

 

[strongm]

Not quite the same thing, though, as the OP seems to be asking for. For example if you use one of those 'common' forms in one project - let's say with a textbox in it - you cannot read the contents of that textbox in another project because each gets their own version.

One way to break this up would be to create code libraries in DLLs ...

 

[vladk]

Yes. It's pretty obvios though. Once I started to do this, I had to keep my eye on versioning, and yes, after the project gets compiled, it will start using it's own "instance" of the form, separated from other executables, using that form.

 

[Golom]

vladk
True enough ... and if we never had to maintain these D*** things it wouldn't be an issue. But since we do ...

Putting out Release 3.2 to fix something bad in 3.1 will pick up any changes in the common objects that may have been made to accommodate the requirements of some other unrelated project.

strongm
I hadn't read the OP's requirement that way but if that was his (or her) intent then of course you're right.

 

[Andrzejek]

Sounds VERY promising….

I gave a try of creating a Project Group using VB Help. It works very nice, but is there any good place, like a tutorial on the Web where I can find out:

How to call other Projects, other Project’s Forms from the same Projects' Group?

How to create a common folder (to place my common Forms and Modules) and

How to call them from there?

Appreciate any help.

---- Andy

PS. I am ‘him’, definitely ‘him’

 

[strongm]

>and yes, after the project gets compiled

Even in the IDE

 

[gjconely]

When you call the different projects, you are simply calling there EXE, DLL or OCX files, not individual objects within that project.

With that in mind, I have started using the "Plug-In" or "Add-In" method to link dlls within a product. I have not done much of this in VB6, but do know it is a little more difficult then doing so in VB.Net - but simply being able to call another DLL or OCX and load it as a tool or something within your main application is pretty straight forward.

To create a common folder is just simply Windows Explorer work. In my VB6 projects folder I have it organized like so:

VB6 Projects
|- Coding
|- Released
|- Common Controls
|- Common Modules

I then keep a master copy of my "modRegistry.bas" file under the Common Modules folder, and just link to it from there when I want to use it.

Greg Conely

http://www.ImageMentor.net

http://www.gregsdirectory.com

 

[vladk]

strongm,

Right, in the IDE too. Quite obvious...

vladk