I know VB is a WTF, but...
-
But sometimes the programmer makes it a little worse.
I'm currently converting some VB6 to .Net, and have come across some weird stuff. For those that know about the CommonDialog object (Windows file selection dialog), in this case it was named CDO:
CDO.Filter = "TXT (*.dbf)|*.txt"
No wonder a few users were confused about whether they should selecting a DBF or a text file.
Later on, after the user has selected the file, this method is used to get the filename:
Dim fso As FileSystemObject
Set fso = New FileSystemObject
Dim strFileName As String, strFileFolder As String
strFileFolder = fso.GetParentFolderName(CDO.FileName)
strFileName = fso.GetFileName(CDO.FileName)I've only just begun, hopefully I'll run into enough that it might constitute a front page WTF. So far it's just been minor stuff like having functions that don't take parameters, they just use global variables. The same global variables are declared on every form, class, and sometimes in a module too, some of which are never used or are only used in one location in the entire program.
Sorry if this is old hat to most of you, I've had the pleasure of working on my own code up until now. I just didn't expect to see this from a veteran programmer.
-
globals are great fun. they become really fun when you want to make your software operate with mutliple threads.
-
It saddens me to see how such an otherwise nice language (especially since .NET) can be destroyed so easily.
I've seen someone handle "threading" with globals and a global
"isBeingAccessed" (can't remember the exact name, but something like
it) bool.
In order to gain access to the globals, you had to check
isBeingAccessed. If it was FALSE, set it to TRUE and do your thing. If
it was TRUE, someone else was using it, so you had to sit in a loop and
try again.
Needless to say buys aplenty, lockups, strange behaviour, etc. The
"threads" in question? Multiple forms and async data access. It was
truly and utterly bizarre. Of course VB got blamed for "being s**t at
handling threads.
-
Doesn't the CommonDiag use the input that the user typed in? CDO.FileName is "SOMELO~1.TXT", where as the file name really is "Some Long Name.txt"?
I'd test it myself, but that'd involve booting the VB6 machine, logging in, etc ... anyone know?
-
I typically don't even bother upgrading VB6 to VB.NET due to the paradigm shift from object based to object oriented (not to mention most VB6ers don't even know the difference).
The last VB6 upgrade I did literally resulted in every line of code having some sort of upgrade warning comment inserted above it. Most of them were due to the fact that every object was either not declared or declared as variant/object. The rest were default property changes such as Me.TextBox = "New Value" was invalid because you need to explicitly set the Text property in .Net.
Another slight WTF is naming the CommonDialog CDO. When I see CDO, I immediately think Collaboration Data Objects. I guess you could tell from context though.
Larry
-
@lpope187 said:
I typically don't even bother upgrading VB6 to
VB.NET due to the paradigm shift from object based to object oriented
(not to mention most VB6ers don't even know the difference).
The
last VB6 upgrade I did literally resulted in every line of code having
some sort of upgrade warning comment inserted above it. Most of
them were due to the fact that every object was either not declared or
declared as variant/object. The rest were default property
changes such as Me.TextBox = "New Value" was invalid because you need
to explicitly set the Text property in .Net.
Now to me, that's just plain ugly. To me, the TextBox is an object, and
you're assigning a string object to it, which makes no sense. I've
always hated those sorts of shortcuts/hacks like that, and the rs!Name
syntax for ADO. I guess that's why my only 2 or 3 VB6>VB.NET
upgrades were relatively painful, but manageable.
Didn't they improve the upgrade process in later versions, though? I've
not tried it, but I'd guess (hopoe!!) that something as simple as a
default property could be changed into an explicit statement before
migrating. Then again...
-
@RayS said:
Now to me, that's just plain ugly. To me, the TextBox is an object, and
you're assigning a string object to it, which makes no sense. I've
always hated those sorts of shortcuts/hacks like that, and the rs!Name
syntax for ADO. I guess that's why my only 2 or 3 VB6>VB.NET
upgrades were relatively painful, but manageable.
Didn't they improve the upgrade process in later versions, though? I've
not tried it, but I'd guess (hopoe!!) that something as simple as a
default property could be changed into an explicit statement before
migrating. Then again...
It was a totally unusable upgrade due to the style/knowledge of the original programmers. Most were self-taught and/or familiar with mainframe languages like COBOL. As you can imagine most of it was procedural and used a lot of globals.
And this was an upgrade done with the the RTM version of VB.Net 2005, so apparently MS didn't focus on migrating default object/control properties. That's pretty much fine by me, since the original code is so f***ed up I'd rather scrap it and start over.
Larry
-
@lpope187 said:
I typically don't even bother upgrading VB6 to VB.NET due to the paradigm shift from object based to object oriented (not to mention most VB6ers don't even know the difference).
The last VB6 upgrade I did literally resulted in every line of code having some sort of upgrade warning comment inserted above it. Most of them were due to the fact that every object was either not declared or declared as variant/object. The rest were default property changes such as Me.TextBox = "New Value" was invalid because you need to explicitly set the Text property in .Net.
Another slight WTF is naming the CommonDialog CDO. When I see CDO, I immediately think Collaboration Data Objects. I guess you could tell from context though.
Larry
As you probably know, the blame lies entirely with the programmers, not the language or the upgrade process. They could have at least read this article on how to code in VB6 so that an upgrade would go smoother:I had to link to the Google cache since the article is so old that it has moved to the subscription only archives. Their #1 suggestion is to stop using default properties (The Me.TextBox = "New Value" syntax). I taught VB extensively since 1995 and I always suggested staying away from default properties. It's not that I'm a genius, every sane developer advocated the same. We also advocated Option Explicit and to avoid Variants. However, the general VB population generally ignored us. Another big one was to avoid the "Dim foo as New bar" shortcut. Most people generally didn't realize the side effects of the shortcut and it upgraded into a horrible mess that preserved all the side effects.
