VB was a natural next step that allowed you to create quick and easy code. If you needed something VB didn’t offer, you could simply add a C++ function or API call in a module and get the job done that way. The point is that you shouldn’t have to type out loads of code (with the possiblity of coding errors) if you don’t have to.

The solution is not that difficult by the way. For every keyword thats “gone” you simply need to write your own function that does the same thing and use the keyword as the name of the function. Create a module that includes all these functions and add it to every project you want to port to .NET.

If you want to make VB open source, there’s your solution. You can even create similar modules for java or other programming languages if needbe.

The set for the same was created using InstallShield.

Windows XP supports this application without any problem/known issue.

However, when I try to install it on Windows Vista, I get an error viz. This application is not supported on this OS. I am really stuck at this point, as number of existing customers want to use Windows Vista.

I know that this may not be the place to raise this kind of question. But I hope all of you can understand my situation and I know that you are using Visual Basic since quite a long time.

Looking forward for your inputs!

A few weeks after I complained to them about the SendKeys issue, I received the following answer from Chris Mayo, the VB Program Manager responsible for Visual Basic 6 on Vista:

———-
re: Vista To Support Legacy VB6 Apps
Pasquale,

I’m the VB Program Manager responsible for Visual Basic 6 on Vista. The SendKeys issues has been corrected and will be released in Vista RC1. The calls to SendKeys that work under Windows XP will work the same way under Vista.

Hope that helps.
Thanks,
Chris Mayo
Visual Basic Program Manager
Sunday, July 30, 2006 7:38 PM by cmayo
———-

You can reach the Blog page at

http://blogs.msdn.com/davbosch/arch…/26/539470.aspx

So, I have to take back what I said. This time the MS staff has revealed to be really professional.

So there are somewhere between 3 and 6 million VB6 developers in the world. That must really stick in the craw of the handful (comparitively speaking) of so-called self-described ‘professional’ or ‘expert’ programmers.

3 to 6 million people who are “stealing” their work; 3 to 6 million who are doing work *they* should do.

So they lobbyed Microsoft to re-engineer the language so that only ‘real’ programmers could use it; to make it so complex that the majority of that 3 to 6 million wouldn’t or couldn’t understand it or use it.

I expect that, if these ‘professionals’ were electronics engineers or builders, they would have bought pressure on companies like ‘Radio Shack’ or ‘B&Q’ for allowing ‘hobbyists’ or ‘amateurs’ to get involved in soldering or DIY.

If these self-appointed experts are so clever, they should spend their time more creatively building applications like ‘VB6′ or ‘MS Access’ which allow computers to be used constructively by the masses.

Dave R of RadSolution (VB programmer of over 10 year’s standing)

Well, in Windows Vista, they have even done away with one of the most common statements used in VB6: SendKeys. All VB6 applications containing that cursed statement will just crash under MS new OS.

In theory, the solution to the problem exists (you have to replace SendKeys with an API function) but what is certainly difficult to do is provide all of your customers with an updated version of the software they bought from you.

If I think of all the VB6 applications I have sold over the last few years which make large use of the SendKeys statement… I can’t believe they now have their days numbered.

What is even more crazy is that SendKeys seems not to work even under .NET 2.0. I really hate it when Microsoft is not compatible with Microsoft!

What’s the point in neutralizing the SendKeys statement when it is equally possible to get the same results resorting to WinAPI32?

Let’s hope this bug will be fixed when the final version of Windows Vista is released, even though I doubt it.

I only used SendKeys to move the focus from a TextBox to the next one or to simulate the pressure of the F1 key in order to launch the help file. I’m afraid millions of VB6 programmers did the same.

Don’t you think it could have been much wiser to neutralize SendKeys only in the case of an interaction with an external application? What should the millions of VB6 developers tell their customers now? “Please, if you decide to upgrade to Vista, don’t ever push the Help button or press Enter to move to the next TextBox, otherwise the program will crash!”

And, besides, don’t you think it is absurd (or even unprofessional) to support SendKeys in .NET 2.0 and make it incompatible with a concomitant operating system?

If you give me teeth, you should not take them away from me the next day.

MS promised that, if a VB6 app works under XP, it will also work under Vista. Let’s wait until next January and see how reliable they are…

On the COM vs NET (i.e., managed vs unmanaged code) framework: personally, I couldn’t care less about this so long as I can still call DLLs, make API calls, build Access databases, and automate Microsoft Office applications. Furthermore, I can’t understand how this dichotomy drives many of the changes made in VBNET. For instance, what’s the deal with making all arrays zero bound? This breaks so much of my existing code that it’s ridiculous, and what’s this have to do with COM vs NET? Sure, I can write a wrapper for each of my arrays so that they are zero bound, but why should I have to? Why doesn’t Microsoft add an “Option ArraysAnyBound” statement to the language which will allow arrays dimensioned with negative subscripts, or whatever. Wouldn’t it be trivial to push this down into the bowels of VB so the programmer doesn’t have to worry with it?

What’s with changing all arguments to ByVal? Once again, why break everything? Why not have an “Option ArgumentsByRef” statement that fixes legacy code? I have gotten VERY familiar with keeping track of what is passed ByRef and what is passed ByVal. Why break so much existing code? Sure, code translators can attempt to fix this, but why do we need to bother?

The “short circuit logic” also breaks a great deal of code. Once again, I can’t see how this has anything to do with the COM vs NET issue. I have gotten very comfortable with using a “Select Case True” statement when I am testing for several conditions and I want to jump over certain evaluations when an earlier one goes true. However, if I write “If ThisFcn() Or ThatFcn() Then” I expect both ThisFcn() and ThatFcn() to execute. In fact, I may depend on it. Once again, why not have an “Option NoShortCircuitLogic” statement in the language?

This one may be a little more difficult, but why do away with fixed strings? I use them frequently in structures (User Defined Types; UDTs), and I know exactly what to expect, even with the invisible ASCII to UNICODE conversion issues when writing to files? Are the hoards of programmers at Microsoft just too lazy to implement this feature?

Why change the value of “True” from -1 to +1? I know that other languages use 0 and 1 (or +1) as true bit operators to indicate “False” or “True”, but, since the beginning of time, a “True” in basic has been a two-byte integer will all the bits turned on (i.e., -1). This brings up another point. What’s the deal with changing the Logical Operators to pure Boolean Operators. Any VB6 programmer worth his (or her) salt knows that all the Logical Operators are actually bitwise operators in all cases. If you don’t believe me, try “Debug.Print CInt(True Xor 5)”. I’ll let you figure out the results. In VB6, when forced to make a Boolean interpretation, such as “If …”, anything that wasn’t ZERO was True. This is why some novices can’t understand why “If 1 And 2 Then …” evaluates to False. However, I digress. The point is, why “break” all existing code that is based on these understandings? Once again, why not have an “Option LogicalsAreBitwise” statement that allows legacy code to execute unaltered?

Why did Microsoft do away with statements that didn’t seem to do any harm. The LSET is a good example. I frequently deal with motion capture data files that have data stored in old DEC VAX floating point formats. I have routines that use LSET to convert this data to the IEEE floating point format. Sure, I can rewrite this code using the CopyMemory API call, but why am I being forced to? In fact, I have some old accounting applications that store data in the old Microsoft Binary Format (MBF) formats from the old QuickBasic days. Rather than writing data file conversion routines, I simply convert the MBF to IEEE in memory, do the math, and then convert back to MBF before I write it to disk. Why break these procedures? They have served me well for decades.

I could go on, but I will stop. To summarize, why not provide a set of “Option ???” statements that modify VBNET to be as compatible as possible with VB6, hopefully, completely compatible, at least at the level of the core language. I will learn how to use the new features, such as multithreading, polymorphism, and overloading as I need them! I would love to upgrade but, because of my extensive library, I am stuck in VB6, and I will badmouth VBNET to younger programmers at every opportunity until the issues of “upward compatibility” are addressed in a respectful and thorough way.

Microsoft would do well to take heed. VB6 is the COBOL of the new millennia. It ain’t goin’ away any time soon! The testing cycles alone to go from 6 to .NET would kill a lot of companies. And as I sit here typing, I listen to Maria Callas, who also has made it to the new millennium, at least on CD.