An "Invalid Key 'Retained'" message usually occurs when you are trying to open a
Visual Basic 6 program using Visual Basic 5. Because a lot of the examples on the
VB Helper site are Visual Basic 6 programs, you may get this message a lot if you
use Visual Basic 5.
Visual Basic 6 is very similar to Visual Basic 5. To convert a
Visual Basic 6 program so you can load it in Visual Basic 5, open
the .VBP file in an editor such as Notepad. Find these lines
(they may not all be present) near the end of the file:
Remove any of these lines that are present and save the file.
If you use classes, remove the initial lines from the .cls module up to and including the END line.
If you do not use any of the new features in Visual Basic 6, you
should now be able to load the project into Visual Basic 5.
(Thanks to Tony Zaradich for
pointing out the DebugStartupOption problem,
Ignacio R. Diaz for pointing out
the CodeViewDebugInfo problem, and
Sergio Perciballi for telling me
how to fix classes).
Note that it really should not be this way. Visual Basic could easily
be smart enough to realize that it is looking at an different version
of Visual Basic instead of a corrupt file. It should open the project
without complaint, ignoring the unrecognized command and warning you
that the project may not be loaded perfectly. I can't imagine why
Microsoft would make it so you cannot load a file for a single new
line in the .VBP file.
Click here for a simple drawing program that
demonstrates a lot of useful techniques including forward and backward compatibility.
Michael Bailey disagrees. He says:
It is quite simple, actually. That's called being backward compatible. Microsoft should have NEVER made anything backward compatible. That's what is holding back the software industry. It's (the industry) is geared towards creating stupid software for stupid people. If we could somehow raise the education level of the common user, we could have some kick-ass software. But, NOOOOOOOOO, they all want to be able to do some "stupid" things, like opening a VB6 app in VB5.
And in regards to your statement of "Visual Basic could easily be smart enough to realize that it is looking at an different version of Visual Basic instead of a corrupt file. "
Well, first of all, don't equate 'intelligence' with software. It's simply a set of instructions which executes within some predefined set of guidlines.
Secondly, I'm glad that the Microsoft Software Engineer's did it that way. If you use VB the way it's "SUPPOSED" to be used, then it is "smart enough". Just open a VB5 project in VB6 and it "knows" there is a difference, and will be "kind"-enough to upgrade it for you.
I'm afraid I have to disagree with Micheal Bailey on this.
I'm afraid that Mr. Bailey's contempt for both users and his peers brings
the entire industry into disrepute.
- The industry is not geared toward creating stupid software, it is geared
toward creating flexible software. Mr. Bailey does not appear to have a
business-related approach to software engineering. If you have a department
equipped with VB5 and VB6's additional features are only useful to one small
project then it would be an enormous waste of money upgrading the entire
department. However code re-use and generic programming mean that there
should be no problem in using code written in VB6 in a VB5 application for
the most part , whether it be a single class or an entire project.
- It is possible to write intelligent software. I have encountered
numerous apps which will, if required, ignore unrecognized lines and prompt
for further guidance. If the "predefined set of guidelines" is flexible
enough then the software can be considered intelligent up to a point.
- Finally, software engineering is about making people's work and lives
easier. Users no longer have to be able to program in assembler in order to
get anything done with a computer. It is the engineer's task to provide
functionality in an easy to use form. This is the way that VB is '
"SUPPOSED" to be used'
Nick K. has these interesting comments to add:
My line of work involves making small little GUI utilities that I distribute
via e-mail. I prefer using VB5 because with it you are pretty much assured
that your programs are going to be able to run on all platforms, without
complaining about a missing VB6 run-time (MSVBVM60.DLL), which isn't present
on most Windows 9x machines.
With VB6, you have to have the added overhead of a bloated packager with the
VB6 run-time in it, which you have to ship each and every time you send a
tool to a new contact, in case they don't already have the VB6 run-time
already, which many do not. This effectively increases the size of a 50K
tool to over a meg -- not fun to transfer over and over again via dialup.
Since VB5's run-time is standard with all but the oldest Windows 95
installations (and even then, there's a 99% chance the VB5 run-time has been
installed by another app) all you need to do is send your utility -- using
API calls instead of OCXs to avoid that hassle as well -- and you're set.
No worries about packaging and deployment. The VB5-compiled EXEs tend to be
a bit smaller too.
So to me, I see nothing but disadvantages to compiling with VB6 over VB5.
I'd dare say that the vast majority of programmers, except those working in
a large team on big apps that really take advantage of the new features, are
needlessly using VB6, simply because it is (was) the "latest and greatest"
thing being pushed by Microsoft. I'd say the same thing about VB.Net,
unless you're a big-time team developer, whats the point? Hundreds of
dollars spent on upgrading, for what marginal benefit?
But back to the issue at hand, I found the info above about how to make VB6
projects compatible with VB5 by just removing a few lines in the .VBP file
very useful indeed. I've "reverted" dozens of small example projects and
have yet to have one complain about a feature in VB6 that is missing from
VB5. Often authors will include a pre-compiled EXE along with the source.
The EXE often complains about the VB6 run-time. A quick re-compile using
VB5 and the problem is solved.
This only confirms my suspicion that many people are needlessly using VB6
when VB5's functionality can handle most projects just fine.