Visual Basic - when to switch?
-
immediately after puberty. :)
>64 Some days the dragon wins. Suck it up.
:laugh:
Software Zen:
delete this; -
I agree with you regarding OOP -- it's A technique, not THE technique. C# is an OO language, so things are pushed in that direction. Something people don't often consider is that forms are classes. Forms in VB 4-6 are instantiable objects. It doesn't matter that the word "class" isn't there -- it's not a requirement, just a common convention. Re-writing an application from scratch is not a trivial thing. It can be rather expensive, and management often defers the task to avoid incurring what appears to be an unnecessary cost. Until replacement becomes a requirement, and things are crammed into production. As the old saying goes, we don't have time to implement correctly, but we do have time to fix it in production.
Very well said! Years ago, when converting a VB6 app, one of my programmers told me I had too much code "behind the buttons". My reply was that sometimes a button click is just a button click. An extreme example, but goes to the "THE" mentality. I don't know about all of you out there, but often times "agile" falls short of design flow. I'd call it more flux-rad. Easy to make the argument that OO is the way to go, but it takes some thought and a couple of lines of procedural code can be a better solution. And, as you said, cost is very often a factor. The other old saying we use is, if it ain't broke, don't fix it!
-
Correct. I should've specified desktop programs.
"If we don't change direction, we'll end up where we're going"
-
I have a very similar situation with software written in 1995 in a mix of QBasic and MS Access, migrated to a SQL server back-end, updated to VB for the QBasic stuff, back-end moved to MySQL, and numerous iterations since. What's interesting to me is the derision shown for powerful, capable and effective systems written in so-called "toy" languages. Many still run today because they just work and do what they were designed to do. I develop mostly in C# now but I would never look down on people still using VB, VB.Net, or any other language. If it works for them, then it must be doing something right. Program-language snobs are something I cannot understand. I will admit that I would never start developing a new project on any of the older languages, no matter how well I know them.
Carl Edwards In SA wrote:
Program-language snobs are something I cannot understand.
I understand your statement but there is a bit more to it that just that. Older implementations can have other problems which management is unwilling to address. For example one often gets to the point that the only way you can find maintenance programmers is by finding someone who doesn't know anything about the older language and convince them that learning that language that is unlikely to be used elsewhere is going to be a good choice for them. To be fair though I have seen a current trend where management has decided that micro-services can be written in any language and with any persisted data store which obviously completely ignores the longer term maintenance costs.
-
When to switch? I'd start now. Nothing ever goes as planned, so figuring things out now, well ahead of a complete drop in support, is the wiser choice. I have no idea where the OP is in his career, but any newer language is a more marketable skill, so starting now also adds to the resume. What to switch to? I was a VB developer (among other languages) from 1993 to 2003. At that point there was still a lot of 3rd party support for VB6, but without MS support it was a dead language. Yeah, obviously as dead as COBOL, but as an IT consultant, I had to focus on marketable skills, and VB was no longer "it". The obvious jump-to was VB.NET, but within a few months I formed the opinion that MS made VB.NET primarily to keep the VB5/6 developer base from jumping ship. VB.NET didn't get the same support and was not graining traction in market share. Next I investigated C#, and that has been my primary platform since then. It's the MS flagship for programming languages, gets the support, and has a viable future. Market share of the tool matters greatly to ensure continued employment, and C# is ranked 5 or 6 in most surveys. From the OP's POV? C# is going to be the easiest path. The environment is similar enough and C# has enough similarities in structure that the learning curve should not be too steep. Jumping from procedural to OO can be a difficult jump. VB6 has some OO, and if the OP has been using classes, the leap may not be a long one.
-
I counted 16 replies to the question of wich I se only two that tried to seiously anwer. I this the normal level of seriousness in this forum?
thermia wrote:
only two that tried to seiously anwer. I this the normal level of seriousness in this forum?
In this forum (not site)? Yes it is is. Although certainly with an open ended question I would expect answers that veer off in all sorts of ways anywhere. But also as the OP and with decades of experience I don't actually need an "answer". If I really needed an solution I would already know what it was and how to apply it for any specific situation I was in. I just thought the question was interesting.
-
never switch. VB Classic was right only now in C# you can write code without
XYZ partial class App public static void main SubscriberMethodController... cough coughStarting in C# 9, you don't have to explicitly include a Main method in a console application project. Instead, you can use the top-level statements feature to minimize the code you have to write. In this case, the compiler generates a class and Main method entry point for the application. guess what, we had that since VB 1.0, any language had that, the compiler behind the scenes generated the _app & _main. i wonder when they are going to get rid ofnewin C#, since the instances of a class are not created on the stack anyway... VB Classic will outlive VB .NET. if not, waiting for the shameful M$ narrative when they bring back the apparent syntax of VB to VB.NET those who put *class* in JavaScript are the same who put *var* in C#Martin ISDN wrote:
guess what, we had that since VB 1.0,
Just noting that I don't consider that a feature that would have any impact at all in a language choice. Further if one is spending a major part of their time creating new applications I would wonder what exactly is the business domain they are working in. After all if you are maintaining an application for 20 years then the entry point for that application should not change at all for the entire time.
-
Visual Basic stopped working with Windows 7. Microsoft dropped a bunch of required modules in Windows 7. The solution was to add these modules to the VB6 build. Again with Windows 10, Microsoft did the same thing, requiring modules to be included in the build. In addition, Microsoft changed the registry structure/contents on Windows 10. I am still trying to code replacement to find the full path to installed programs. Years ago, I was going to convert my VB6 programs to VB.net, but ran into big problems as the form handling routines did not have the same capabilities of VB6. That was probably 18 years ago, so I can't remember the details now, but I'd guess, and it is only a guess, that things like _LostFocus no longer worked and I didn't want to waste the time on how to get around the problem. As I recall, there were a lot of deficiencies with VB.net. With changes in Windows 10 and Windows 11, I may have to re-write all my applications in a new language. I've been retired for over 10 years, so I don't think that is going to happen. Microsoft sucks! And don't get me started on the 'unknown publisher' message that comes up every time I run an application on Windows 10. Microsoft doesn't want to make things easy for the developer anymore.
LucidDev wrote:
Microsoft doesn't want to make things easy for the developer anymore.
Presumably you are referring to the Basic domain only because as far as I know Microsoft never had an actual vision to make any easy for developers. It was always about the money.
-
LucidDev wrote:
Microsoft doesn't want to make things easy for the developer anymore.
Presumably you are referring to the Basic domain only because as far as I know Microsoft never had an actual vision to make any easy for developers. It was always about the money.
Yes, you are correct. My comment was based on MS saying they would continue to support VB6 until..... VB6 is not supported 'as is' on current OSes. After adding in missing support modules in the build and installation process, applications could run for the most part on Windows 10. Some clients complain that the code does not work on Windows 11, but I don't have a Windows 11 system to test it on. I use Visual Installer to build my install files and asked them to test an install on Windows 11. They said it installed fine, so I don't know why one client had a problem. Another technical problem is that before Windows 10, you could get the full path to an executable by going to the registry entry "HKLM\software\microsoft\windows\currentversion\app paths\" where is the file name of the application, like "Outlook", for example. Not anymore!
-
BryanFazekas wrote:
I have no idea where the OP is in his career,
The OP (me) has about 40 years. And I don't use any version of VB if I can avoid it. My choice is Java or C#. I was just posting because I found the subject interesting.
Regardless of the language(s) involved, application replacement is a good topic for discussion. As I said, management typically doesn't want to spend on re-developing an application when there is time, but freaks when there isn't time and they did nothing to help the situation. A project I was on a while back was replacing an ancient application that relied on old tech. Everyone (customer, management, dev teams) dragged their feet on putting the new system in production, until key tech the old application required was dropping support. We completed the project in 3 months. It's amazing how a bit of heat, or maybe a raging bonfire, can motivate people. :laugh: Personally, I'd have no problem developing in VB again. Prior to VB, I mostly used C and Hypercard (Mac folks may remember that one), and a handful of other languages. VB was fantastic for productivity in creating desktop applications, far better than anything on the market at that time. Honestly, it's better in that venue than anything I've worked with in the last 10 years. When the only tool ya have is a hammer, everything looks like a nail. That's the case for OO, Agile, RAD (yeah, I'm as old as the OP), and every other paradigm. Before someone mentions "VB has GOTO" ... C# has GOTO and Java originally did (AFAIK, it's just a reserved word now). Bad code can be written in any language, and I've seen more in C# and Java than I have in VB. A lot depends on one's POV. My job is not to write code. My job is to solve business problems, regardless of methodology or tools. Food for thought.
-
Yes, you are correct. My comment was based on MS saying they would continue to support VB6 until..... VB6 is not supported 'as is' on current OSes. After adding in missing support modules in the build and installation process, applications could run for the most part on Windows 10. Some clients complain that the code does not work on Windows 11, but I don't have a Windows 11 system to test it on. I use Visual Installer to build my install files and asked them to test an install on Windows 11. They said it installed fine, so I don't know why one client had a problem. Another technical problem is that before Windows 10, you could get the full path to an executable by going to the registry entry "HKLM\software\microsoft\windows\currentversion\app paths\" where is the file name of the application, like "Outlook", for example. Not anymore!
LucidDev wrote:
you could get the full path to an executable by going to the registry entry
No that is not true as stated. If you 'installed' it then it was true. And apps specific to Windows itself were all installed so they would show up there. Well at least once that really started to be used. Not sure how that wouldn't still be true because I think that is needed for the 'uninstall' to work from the Programs applet. Perhaps they moved it. I just checked on Windows 10 and I see Outlook is still there. Since individual components would independent maybe they have moved some but not others.
-
LucidDev wrote:
you could get the full path to an executable by going to the registry entry
No that is not true as stated. If you 'installed' it then it was true. And apps specific to Windows itself were all installed so they would show up there. Well at least once that really started to be used. Not sure how that wouldn't still be true because I think that is needed for the 'uninstall' to work from the Programs applet. Perhaps they moved it. I just checked on Windows 10 and I see Outlook is still there. Since individual components would independent maybe they have moved some but not others.
In Windows 10, all of the installed applications are located in this registry key: "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant\Store\" Unfortunately, I have not been successful in searching or storing the data to search for the application I am looking for. One of the suggested solutions was, as you imply, is to look for uninstall information. Unfortunately, not all applications can be located using this method. My point is that MS said that VB6 would continue to be supported, but they keep changing the OS making that impossible. If you happen to have code that can read the referenced key into an array, I would appreciate seeing it! Thanks.
-
In Windows 10, all of the installed applications are located in this registry key: "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant\Store\" Unfortunately, I have not been successful in searching or storing the data to search for the application I am looking for. One of the suggested solutions was, as you imply, is to look for uninstall information. Unfortunately, not all applications can be located using this method. My point is that MS said that VB6 would continue to be supported, but they keep changing the OS making that impossible. If you happen to have code that can read the referenced key into an array, I would appreciate seeing it! Thanks.
Ah...I was thinking you meant it was being kept is some completely different storage mechanism. At any rate for any new major OS version you must always fully regression test it. And then adjust for differences. Maybe VB was hiding that at some point but perhaps more likely is that the dependencies you had your app(s) just didn't move between major versions for a while. So you got lucky. Now they moved so you must adjust.