Re: Compile errors in VB6 running in VirtualPC
- From: "Ralph" <nt_consulting64@xxxxxxxxx>
- Date: Mon, 17 Dec 2007 19:17:21 -0600
"Orcbighter" <Orcbighter@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:DA092898-8D36-4B0C-85A6-F2283FCFD5A1@xxxxxxxxxxxxxxxx
Hi,V6
I have struck a problem and am hoping someone here knows the answer.
I am running VirtualPC 2005 with WinXp32 SP2 installed, and Visual Studio
(VS6) and Visual Basic V6 (VB6). The host machine is running WinXP64.I
The source code for my projects is on a shared folder on the host PC. When
tried using the shared folders function within the Settings window of thefolder
VirtualPC console I found two things. Firstly, C++ projects in VS6 had no
problems. Secondly, VB6 projects did.
The host folder D:\VirtualMachines\VMData was mapped to the VM as D: drive
using the "Shared Folders" functionality of VirtualPC. Inside the VM it is
displayed in the Windows Explorer tree as "Network Drive (D:)"
Trying to open VB6 projects would fail with "Path not found
'\\D:\\VMData\src\MyProject\MyProject.vpb'. The path should be
D:\src\MyProject\MyProject.vbp
To overcome this problem I stopped using the "Shared Folders" function in
the Settings window. Instead, from inside the VM, I mapped the shared
on the host pc as a network drive. Inside the VM it is displayed in thelets
Windows Explorer tree as "VMData on 'HostPC' (D:)".
This overcame most of the problems. The VB6 IDE could now open and compile
projects and run them. However, a new problem has become evident.
I have a project that uses some activeX components from other projects;
call them MyFirstDLL and MyOtherDLL. I find that code referencing theseUser-defined
object fails to compile and generates an error "Compile error:
type not defined".
The code takes the form:
Public Sub funcA( ByRef p1 as MyFirstDLL.method1, ByRef p2 as
MyOtherDLL.method2)
.
End Sub
When I look in the References dialog of the Project settings, and click on
the component, I find the same problem in drive mapping.
I have tried unselecting the object, then browsing to the DLL and actively
selecting it, but the location displayed is not
D:\src\MyProject\Release\MyProject.dll, it is
\\HostPC\VMData\src\MyProject\Release\MyProject.dll, which, of course, it
cannot find.
Can anyone explain what is going on, and suggest a possible
work-around/solution?
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
.
- Follow-Ups:
- Re: Compile errors in VB6 running in VirtualPC
- From: Orcbighter
- Re: Compile errors in VB6 running in VirtualPC
- References:
- Compile errors in VB6 running in VirtualPC
- From: Orcbighter
- Compile errors in VB6 running in VirtualPC
- Prev by Date: Compile errors in VB6 running in VirtualPC
- Next by Date: Re: Compile errors in VB6 running in VirtualPC
- Previous by thread: Compile errors in VB6 running in VirtualPC
- Next by thread: Re: Compile errors in VB6 running in VirtualPC
- Index(es):
Relevant Pages
|
