Old Programmer Question
-
5 was closer to 6
Real programmers use butterflies
Closer than what?
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
Closer than what?
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013VB5 is closer to VB6 than it is to VB4. VB4 didn't do native compilation, IIRC and it still had a 16 bit support portion, again if i remember correctly.
Real programmers use butterflies
-
GWBasic predated windows. VB4 was mostly just GWBasic with a code generator. The code generator for Windows had gotten fairly good by that time. When they got to VB6 they had added a lot of object oriented features. Where did VB5 stand in this evolution. Was it closer to 4 or 6?
So many years of programming I have forgotten more languages than I know.
michaelbarb wrote:
Where did VB5 stand in this evolution. Was it closer to 4 or 6?
IMO, VB5 was closer to VB6. VB4 added classes, and added 32-bit support in addition to VB3's 16-bit. VB5 was 32-bit only, added the ability to create controls, and compiled to native binary. It was part of Visual Studio 97, Microsoft's first attempt (AFAIK) at an integrated development environment. VB6 added the ability to create web applications. It was part of Visual Studio 6 -- Microsoft standardized on v6 for all included products, as I recall VB6 had the highest version. I don't recall that the core language changed much between versions. Unlike recent versions of C#, the big difference between versions was major additions to capabilities. VB4 applications would compile in VB5, and IIRC, in VB6. Compiling down worked unless the program used features not available in the earlier version of VB. How does one "convert" a VB program to C#? Circa 2003 I tried migrating VB6 programs to VB.NET, and that was a dismal failure -- it was much faster to completely rewrite the program in VB.NET than to try fixing the migrated version. I'm picky on wording as it affects my response. If you're re-writing the programs, as long as you can read the intent of the VB code, I don't believe it will make much differences in what version the original program was written in. Note: just for the heckuvit I searched on VB to C# converters -- I found several products that claim to do it. My first thought was "why?", as VB6 has been unsupported for 12 years and effectively dead for 15+ years. However, in the "top 20 languages" surveys I've read over the last few years, VB typically ranks 12 to 15. There's a LOT of VB programs out there, and management isn't going to pay to convert a program unless it's broken ....
-
VB5 is closer to VB6 than it is to VB4. VB4 didn't do native compilation, IIRC and it still had a 16 bit support portion, again if i remember correctly.
Real programmers use butterflies
I was being a smart-ass. I actually don't care about VB... :)
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
I was being a smart-ass. I actually don't care about VB... :)
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013Who does? TBH it's just useless trivia I know from the bad old days.
Real programmers use butterflies
-
In another universe they never developed .NET They have versions of 7, 8, 9 ... That universe is often know as DLL Hell.
So many years of programming I have forgotten more languages than I know.
-
michaelbarb wrote:
Where did VB5 stand in this evolution. Was it closer to 4 or 6?
IMO, VB5 was closer to VB6. VB4 added classes, and added 32-bit support in addition to VB3's 16-bit. VB5 was 32-bit only, added the ability to create controls, and compiled to native binary. It was part of Visual Studio 97, Microsoft's first attempt (AFAIK) at an integrated development environment. VB6 added the ability to create web applications. It was part of Visual Studio 6 -- Microsoft standardized on v6 for all included products, as I recall VB6 had the highest version. I don't recall that the core language changed much between versions. Unlike recent versions of C#, the big difference between versions was major additions to capabilities. VB4 applications would compile in VB5, and IIRC, in VB6. Compiling down worked unless the program used features not available in the earlier version of VB. How does one "convert" a VB program to C#? Circa 2003 I tried migrating VB6 programs to VB.NET, and that was a dismal failure -- it was much faster to completely rewrite the program in VB.NET than to try fixing the migrated version. I'm picky on wording as it affects my response. If you're re-writing the programs, as long as you can read the intent of the VB code, I don't believe it will make much differences in what version the original program was written in. Note: just for the heckuvit I searched on VB to C# converters -- I found several products that claim to do it. My first thought was "why?", as VB6 has been unsupported for 12 years and effectively dead for 15+ years. However, in the "top 20 languages" surveys I've read over the last few years, VB typically ranks 12 to 15. There's a LOT of VB programs out there, and management isn't going to pay to convert a program unless it's broken ....
The manual had a lot of screen shots. It was not that difficult to read the code for the control and duplicate it in a WPF. I feel that doing it in a Window Forms would have been harder. I developed a new appreciation for XAML. The code behind was the usual problem of converting basic to C#. The biggest problem was the program was flat. Without the Object Oriented guides there were a lot of references between windows. All parameters are basically global. Kind of like spaghetti(luckily there are no goto statements any where). I tried some binding in the beginning but with so many I gave up. I figured out how to do a flat WPF. Having all window open and using Show/Hide. I set up a static class call "g" for global an put a lot of parameters in it. That exercise in itself was interesting and I was thinking of writing it up. Not recommended, just interesting. Thinking of binding, I realized it is kind of like the new spaghetti. Someone ask why convert. In the medical industry validation is just part of cost and will be added in eventually. The machine did a destructive test so it only had to do a few each month. Even being run very little eventually the Windows 95 computer is starting to die. The goal is to get the new program to look and run as closely to the old one as possible. This will minimize the cost of paper work to validate the replacement. I call this job security.
So many years of programming I have forgotten more languages than I know.
-
Whole parts of my brain just opened up, creaking and dusty, at the mention of GWBasic. Good memories...
cheers Chris Maunder
-
The manual had a lot of screen shots. It was not that difficult to read the code for the control and duplicate it in a WPF. I feel that doing it in a Window Forms would have been harder. I developed a new appreciation for XAML. The code behind was the usual problem of converting basic to C#. The biggest problem was the program was flat. Without the Object Oriented guides there were a lot of references between windows. All parameters are basically global. Kind of like spaghetti(luckily there are no goto statements any where). I tried some binding in the beginning but with so many I gave up. I figured out how to do a flat WPF. Having all window open and using Show/Hide. I set up a static class call "g" for global an put a lot of parameters in it. That exercise in itself was interesting and I was thinking of writing it up. Not recommended, just interesting. Thinking of binding, I realized it is kind of like the new spaghetti. Someone ask why convert. In the medical industry validation is just part of cost and will be added in eventually. The machine did a destructive test so it only had to do a few each month. Even being run very little eventually the Windows 95 computer is starting to die. The goal is to get the new program to look and run as closely to the old one as possible. This will minimize the cost of paper work to validate the replacement. I call this job security.
So many years of programming I have forgotten more languages than I know.
I've worked on validated applications so I understand your plight. Instead of a global class, I've created MDI applications and used the MDI parent as the container for all global information. However, that approach messes up your validation ... One approach that might help is to create your global object as a class field in the first form. As other forms are created, pass the object by reference to the new forms. IIRC, that should provide what is essentially a global object without actually making it global. You're probably far enough into it that you don't want to backtrack -- just a thought.
-
Whole parts of my brain just opened up, creaking and dusty, at the mention of GWBasic. Good memories...
cheers Chris Maunder
*Good* memories?
Cheers, विक्रम "We have already been through this, I am not going to repeat myself." - fat_boy, in a global warming thread :doh: