|
You can see from most of the replies, cargo cult programming is common in VB6.
I had to deal with this sort of thing in code written for VB.NET but with Option Strict Off 
Regards,
Mark Hurd, B.Sc.(Ma.) (Hons.)
|
|
|
|
|
Yes, I'm particularly surprised that in spite of writing explicitly why it is inappropriate in this case (to convert long->string->long), that people still post to indicate "this is a common idiom in VB6". I'd rephrase that as "this is a common idiocy in VB6". Cargo-cult programming sums it well too.
I see why VB6 has such as bad reputation - and its not the language for the most part, and why programming languages aimed at mainstream use should take steps to protect programmers from themselves (strong typing, correct scoping, eliminate global variables, and make bad-idioms a struggle to use).
I wonder if there's a cargo-cult approach on message boards too, where if you keep repeating the same wrong reply it will magically begin to work.
"Insanity: Doing the same thing over and over again and expecting different results". Albert Einstein.
modified 4-Jan-13 16:05pm.
|
|
|
|
|
Slightly in defence of the VB.NET Option Strict Off equivalent, I did see it provides a more user friendly error message. (Programmatically it loses information, because the exception type is always the same, but the error message actually displays the invalid "value".)
This is NOT a defence of the current Long->String->Long scenario though.
Regards,
Mark Hurd, B.Sc.(Ma.) (Hons.)
|
|
|
|
|
From some legacy VB6 code I'm in the process of making redundant...
Thanks
seobook
|
|
|
|
|
I've always told it: It's better to be in the safe side... 
|
|
|
|
|
This is a standard VB6 idiom for dealing with data that might contain a Null value.
|
|
|
|
|
...and in my replies above I've already indicated why it is unnecessary to convert long->string->long.
modified 4-Jan-13 16:14pm.
|
|
|
|
|
I'm still boggled a bit by the number of people who responded "this is a common idiom" without actually analyzing what was written. It's not that I'm not familiar with why it happens, it's just that so many who reply this way are being paid good money to manage code bases.
"Seize the day" - Horace
"It's not what he doesn't know that scares me; it's what he knows for sure that just ain't so!" - Will Rogers, said by him about Herbert Hoover
|
|
|
|
|
cpkilekofp wrote: I'm still boggled a bit by the number of people who responded "this is a common idiom" without actually analyzing what was written.
Good, it's not just me then.
|
|
|
|
|
Hi, Greetings from {London|Austin|NY|...}.
Something tells me that something has gone wrong with the blog comment auto-generator at this blog here[^].
Kinda backfires when the auto-generated comments aren't processed, and, well, the result is a thing to behold!
|
|
|
|
|
Bob Dole The internet is a great way to get on the net.
 2.0.82.7292 SP6a
|
|
|
|
|
Unholy mother of spam 
|
|
|
|
|
private void toggleSwitch(bool? visible = false)
{
if (visible.Value) toggleState(visible);
}
|
|
|
|
|
Well, it is completely redundant, and why is it Nullable?
I guess the developer had a case of hypocaffenia and encountered a '404: Brain Not Found' error.
Bob Dole The internet is a great way to get on the net.
2.0.82.7292 SP6a
|
|
|
|
|
Zac Greve wrote: hypocaffenia
Love it! 
|
|
|
|
|
It's entirely possible that they would pass null into toggleSwitch. Of course, it should be HasValue rather than Value.
|
|
|
|
|
It's not redundant at all. But it probably doesn't function the way the author intended. What the author probably had in mind was:
private void toggleSwitch(bool? visible = false)
{
toggleState(visible);
}
...which wraps a non-nullable toggle function with a nullable one.
But as it is written, the functionality that this method offers is actually:
1. If user passes toggleSwitch(True), then toggleState is toggled. BUT,
2. If user passes toggleSwitch(False) or toggleSwitch(), then NOTHING happens (because of the test).
|
|
|
|
|
Congrats. You have successfully installed bugs!
|
|
|
|
|
Granted you don't pass a null value, the component / control will always remain in
.Visible = false But if false is passed, there's nothing there that will turn the control /component back on again.
|
|
|
|
|
It throws an exception when visible == null.
|
|
|
|
|
I'm rebuilding an old web app from scratch and I found this. There's a page that has a bulleted list on it.
Here's an example of how this was acheived:
<table border="0" cellpadding="1" cellspacing="0" style="width: 690px; height: 297px">
<tr>
<td align="center" style="width: 20px; height: 28px; vertical-align: top; text-align: center;">
•
</td>
<td style="width: 715px; height: 28px; vertical-align: top;">Text in here for list</td>
</table>
Why use UL when you can use a table, and actually put the bullet in manually as a whole separate column!
The second TD being wider than the whole table is also a nice touch.
|
|
|
|
|
|
Maybe it was generated from a DB table and they already had a stock routine to convert a result set into a table?
call dump_table("SELECT '*', column1 from table1 where listName = 'first';");
There could also be javascript code that captures clicks on table cells?
|
|
|
|
|
There's nothing like that. It's a static FAQ page.
|
|
|
|
|
screen readers? 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
