VB Forum / COM / December 2007

User-defined

Warning unsatisfactory reply follows ...

For years, I have seen dozens of shops try and come up with some scheme to
run the VB6 IDE off a wire, from shared folders, or some other wild
combination. None of them, repeat NONE, in 15 years, has ever completely
worked. It is just an endless series of leaks - patch one, another springs
up someplace else. <g>

My advice, don't go there. VB enjoys, essentially demands, that it is the
sole animal in its domain. It shares poorly, mostly because it doesn't even
consider that it has to share. "Sharing" is not in its vocabulary.

As a partial explanation, let's compare the VB IDE to the VC++ IDE (VS). VS
is MDI application that manages files. In VS everything, is a file - there
is a resource file, code files, browser files, incremental link files,
project files, workspace, etc. Various tools are called upon to mangle or
manage the files.

For a simple project VS opens the project file, reads the names of the
files, and offers them for editing. Then it sits there. You open a code file
make a change and save it. VS sits there and waits. You want to compile, it
launches the compiler which does its thing on the 'saved' file, reports back
through a T any errors it finds, and places the results in a 'file', and
sits there.

Or look at it this way, the VS does nothing that you couldn't do from the
command line if you wanted. Except launch the MSVS editor or designers of
course - but you can always use a 3rd party substitute. In fact VS will
allow you use your own toys in the IDE as much as you want.

In contrast the VB IDE constructs its own internal image of a project and
creates its own temp files and caches. When it 'loads' a code file, say a
BAS, it actually builds an internal image of that file in pcode. In other
words what you see in the "editor" is not actually the file - it is VB's
presentation of that file. That's how it can correct spelling issues, and
knows if a variable is defined elsewhere, etc. Its always running, always
scheming.

It also highjack the Registry on start-up, building it own redirection
paths. For example, all referenced Dlls are routed through VBdebug.dll. It
caches control information in OCAs which it uses internally instead of the
COM entry for a OCX.
So the 'program' or code you see is not actually attached/bound to the
component like it will be when compiled - the code is an internal image
which is bound to VBDebug.dll. Unfortunately -  As you have discovered it is
not uncommon for it to confuse where it got something from with where it is
'supposed' to be in his opinion.

BAS, CLS, FRMs, files are just by-products to VB. They are of interest going
in and of interest in leaving. But during he could care less. It assumes it
has complete control of everything and it is all in one folder. (He is
mildly tolerant of sub-folders, etc on the same machine. <g>) The VB is a
working application always churning on what it in its own symbol tables,
caches, temp files, etc.

I know this a poor view and far too wordy. Obviously VB is more complicated
than what my feeble attempts to portray it.

The best way to manage a multiple developer/machine VB environment is to
create Sandboxes. ie, each developer when he loads a project needs to
assembly all the items and store on his machine or his vitural working
space. Work from that store - and then put back what has changed. Obviously
a good SCCS is required.

Don't try to manage VB6 projects the same as a VS one. It only leads to
heartbreak. Note I didn't say it was impossible. What in programming is
truly impossible? Only that is never worth the time and agravation. <g>

If you have some pointy-haired boss that is demanding you configure VB this
way - then make sure he is fully aware you will be spending time fixing
leaks and budget accordingly.

-ralph