|
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. 
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.
|
|
|
|
|
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?
|
|
|
|
|
|
I counted 28 words in your comment, and 7 were not correctly written... is this the normal level of working keyboards at your end? 
Sorry... too tempting
To answer you...
The answers of "30 years ago" is for me totally serious. You can infer that the author thinks the OP should not "waste" any second more at all using it and move on to other languages. The fact that it got 10 upvotes means, that many other people (me, among them) agree with him.
And for me it is a perfect serious answer, although it is written with humor.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
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 cough
Starting 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 of new in 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.
|
|
|
|
|
|
As I see it VB6 is the same as visual basic for applications. So as long as they are going to support VBA it seems logical Microsoft will have to support VB6.
My concern is that the Microsoft people are not merging VB.net nominclature with C#. They share the same code base now, so why not upgrade the editor to handle both syntax in one environment. That way there would never be a need to retire either one. Computers are powerful enough to support that structure now which may not have been the case years ago.
I prefer personally "if then ....... end if" for tracing purposes over the c# equivalent which ends everything with a }. Nested loops with everything sharing the same ending are much more difficult to debug. Thank you.
|
|
|
|
|
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 <controlname>_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.
|
|
|
|
|
I wrote a Software Defined Radio in VB6 + Delphi + Assembler back in 2003, and it's still in use today - I still see downloads - https://www.g8jcf.uk/. The Delphi & Assembler were used to write the low level DSP and vector arithmetic - it was developed on a Celeron 333 with 192 MBytes of RAM a SONY VAIO laptop !!!
The G8JCFSDR is a hobby program for free for a relatively small base, so it's not worthwhile me porting it to C#, although it might be an interesting excercise.
Back in 2003, so much stuff had to be added around VB6 to hook message events, handle callbacks, etc, so it might be much easier/quicker today
Ah those were the days 
73
Peter - GM8JCF
|
|
|
|
|
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\<programname>" where <programname> 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.
|
|
|
|
|
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.
|
|
|
|
|
From my viewpoint it depends on what the code is for. I converted my VB6 programs to VB.NET over 20 years ago. Some things took very little effort as I was able to copy large chunks of code. I redid all of my forms from scratch, but I was able to reuse a lot of code.
Most of the code I have written involves controlling test equipment and taking measurements. I like VB.NET because it is easier for someone with very little programming experience to follow what the test code is doing.
|
|
|
|
|
[disclaimer: I supervise a varied codebase that includes a few large VB apps, with many thousands of lines of code.]
Interesting responses to this, ranging from funny to pragmatic to completely off-base.
You need to look at these as IT projects and define your timelines based on need. You didn't provide any details about what the apps are or how they are used, so it's hard to do a decent analysis. Short answer: I'd look at 5-6 year target zone. No sense on pushing it to the limits. Depending on the apps involved, the write could take a few years so starting sooner is better than later.
There is no "re-factoring"; this is a ground up, blank canvas rewrite for desktop apps. C# is the way to go but VB.net isn't terrible. But there's a lot of unknowns:
Are these just small apps serving limited functionality? Data connections and underlying database? Personally, I'm not a fan of migrating databases and codebase at the same time if it can be avoided. It interjects a ton of potential errors. Whether it's data first or code first depends on circumstancePrinting. Many old VB apps do a lot of document printing (not reports). They take a lot of code/time in .net OOP analysis. Meh. Not knowing the codebase, can't answer that one. It's not trivial, and it can be tough to flesh out because you're looking at the existing app. Like anything else, lots of thinking here. Web? Two pronged-question. In our review of some of the VB uses, web-based apps are a more suitable replacement than rewriting desktop apps. We have several going in that direction, though the back end remains in .net in some cases. The second piece is if the apps or data interact with the internet as that plays into the design. It boils down to the apps; how big they are and what they do. I'd start planning as soon as time allows. If you can transition functionality to a new program, it's not a bad approach. Avoid the light switch approach if you can.
|
|
|
|
|
That's an issue for my successor to deal with - I'm retiring in no more than 3 years from now, so I'll just keep going with VB.Net. The programs I'm dealing with were here before I was hired, and I have no doubt that they'll still be around after I'm gone, so I don't feel a pressing need to change anything.
|
|
|
|
|
As the subject says - Google is ending its programming competition. There will be a final round (without prizes or progression) and then they will be removing all trace that it existed.
Sad times - I enjoyed the challenge.
Oh well, there is still Meta Hacker Cup... for now.
|
|
|
|
|
RainHat wrote: Google is ending its programming competition.
Does it qualify to appear on KilledByGoogle.com?
(looking at that list...who would want to commit any resources to anything produced by Google? Seems like they have the attention span of a 2-year old...)
(And stinks just as much)
|
|
|
|
|
It is already there - under Google Code Competitons, along with Hash Code and Kick Start.
It seems the lifespan of any Google project is 6-10 years.
|
|
|
|
|
|
I am clearly developing the wrong kind of software. 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
