Re: Converting Quick Basic to Visual Basic

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Hi Mike,


"MikeD" <nobody@xxxxxxxxxxx> wrote in message news:#5Rq97iPKHA.3876@xxxxxxxxxxxxxxxxxxxxxxx


"Bill McCarthy" <bill@xxxxxxxxxxxxx> wrote in message news:eclMuEbPKHA.3876@xxxxxxxxxxxxxxxxxxxxxxx


"MikeD" <nobody@xxxxxxxxxxx> wrote in message news:#z25iUYPKHA.352@xxxxxxxxxxxxxxxxxxxxxxx
I don't think you could have heard that quite right. VB1 - VB5 code will work in VB6 with only minor changes, if any, required.

That presumes that the application used NO third party controls. VB3 or earlier applications cannot be opened directly by VB6 IDE, and also require replacement of control libraries etc, etc. The claim that code from VB1 works in Vb6 is only for the most simple of cases, and the same can be said for VB6 to VB .NET in simple cases. In the real world people talk about applications, and 16 bit VB, aka VB3 and earlier (also VB4 in 16 bit mode), are NOT compatible with VB6: even the fundamentals such as String are different.


Can't really agree with you Bill.

If you have a compatible, 3rd-party 32 bit OCX, there are few if any problems. The problems come when there's no 32 bit OCX equivalent for a VBX. At the time, most VBXs that were still supported by their authors had 32 bit OCX versions (granted, not all, but most). Finding those now might be a real challenge, though.


And finding ones that are truly compatible was always difficult.



I can't agree at all that VB1 to VB6 only works "for the most simple of cases". That's simply not true. I'm not saying you could open every VB1 (or even VB3) project and it'd work immediately in VB6. VB6 will open .MAK projects PROVIDED source files were saved as text (VB6 will not open source files saved as binary). I just tried it against a relatively simple VB2 project that I still happened to have.


As you said, you tried it against a "simple" project.


I got the message: "This file was saved in a previous version of Visual Basic. When saved, it will be saved in the Visual Basic 6.0 format." There were 2 buttons...."OK" and "Ok For All". Then I got a dialog box regarding data access objects and asking if I wanted to add a reference to DAO 2.5 Object Library. I clicked "Don't Add". Then I pressed F5 and it ran fine.


Yep and you can do the same for simple VB6 to VB .NET projects too.


Internally, the String data type is different than in VB3 and earlier, that is true. But for the most part, this is completely transparent. You still declare a String the same way and you assign and use strings the same way.


On this we agree. The changes to string though were important for those using or wanting Unicode (sadly it never propagated throughout VB properly until .NET). The changes did however break existing VB code, and at least one of the anti .NET crowd in here still harps over that change. The thing was people were trying to use a string for binary data, ignoring the abstraction, then cried when the underlying storage changed. I think the funniest response to that was to say to create another type of String... could you imagine if every object had to have an ansi string property and a unicode string property for each property. I think those ignorant of unicode and globalization needs argued for that on the hope that only ansi strings would prevail: silly and narrow sighted really. The change was for the best (although it could still have been better as per string in .NET), and that change required a breaking change: if however you sticked within the abstraction you'd never notice.


Now, API functions are a different story. All 16 bit API declarations, at the very least, need changed to a 32 bit declaration. Many 16 bit API functions either don't exist, behave differently, or have an alternative Win32 API function. So yes, if you used API functions in your 16 bit VB apps, you had some work to do to get it to run in 32 bit VB versions.



Right. And many controls and third party components changed too for this same reason.


There was no reason whatsoever to even bring up VB.NET. It's completely irrelevant in this discussion.


We're talking versions of Basic, in particular Visual Basic. It is relevant.












.

Quantcast