• (cs) in reply to Niels
    Niels:
    If an 'as designed' feature of a programming language makes it to this site then one might wonder where the real problem lies. Is it the programmer or is it ... ?

    Well there's certainly a problem with a programmer.

  • (cs) in reply to Someone
    Someone:
    Bob:
    "DECLARE @QUERY AS VARCHAR(1000)"

    First time I've WTFed out loud in a while.

    I am being serious here. What is wrong with that line of SQL code?

    I have seen plenty of huge SQL projects that build dynamic queries inside stored procedures exactly as shown here.

    if you really are being serious, why would you do this:

    DECLARE @QUERY AS VARCHAR(1000)
    

    SET @QUERY = 'SELECT NUMTASK, YEARTASK, DATEOPEN '
SET @QUERY = @QUERY + 'from TaskStudio '
SET @QUERY = @QUERY + 'WHERE ( '
SET @QUERY = @QUERY + 'CODCOMPANY = ' + CONVERT(VARCHAR,@CODCOMPANY) + ' AND '
SET @QUERY = @QUERY + 'DATEOPENINGS = ''' + CONVERT(VARCHAR,(CONVERT(DATETIME,@ DATEOPENINGS,103))) + ''' AND '
SET @QUERY = @QUERY + 'CODCLIENT = ' + CONVERT(VARCHAR,@CODCLIENT) + ' AND '
SET @QUERY = @QUERY + 'OFFEREURO = ' + CONVERT(VARCHAR,@OFFEREUROVAR)
SET @QUERY = @QUERY + ' ) '
    

    PRINT (@QUERY)
EXEC (@QUERY)

    instead of this

    SELECT NUMTASK, YEARTASK, DATEOPEN 
from TaskStudio 
WHERE ( 
CODCOMPANY = @CODCOMPANY AND 
DATEOPENINGS =  CONVERT(VARCHAR,(CONVERT(DATETIME,@ DATEOPENINGS,103))) AND 
CODCLIENT = @CODCLIENT AND 
OFFEREURO = @OFFEREUROVAR
 )
  • Schmigz (unregistered) in reply to spamcourt
    spamcourt:
    "More JavaScript. Is it a string or an integer?" if (obj.value>="9000" && obj.value<=9999)

    Vegeta, what does the scouter say about his level? IT'S OVER NINE THOUSAND!!!!!

    BEST...

    COMMENT...

    EVERRRRRR!!!!

  • Anonymouse (unregistered) in reply to Someone You Know

    We use Dynamics GP as our accounting software. It does crap like this all the time... I especially love running a trace trying to find some data to find that the data I want comes from a stored procedure that is created on the fly and then exec'd.

    Argh...

  • Chris (unregistered) in reply to OhDear
    OhDear:
    Some of that code slightly makes sense. I have used old VB and ended up writing some pretty stupid looking code to get around some very stupid language "features".

    A perfect example was when a single x+=1 had to be replaced with x=x+1. Why the first wouldn't work where it was while the second worked fine made no sense, but it made the code function. I can see someone following me and thinking that I was a dolt.

    Maybe that was just a poor example (I can only read VB slowly and cannot speak it), but x = x + 1 is not stupid. Some prefer it because it is more readable (I don't).

    The examples in the article would have taken the idea of x += 1 and said in psuedocode ...

    if x == 0 x = 1 else if x == 1 x = 2 else if x == 2 x = 3 ... you get the idea

    Now that IS stupid in any language and more like the article.

  • (cs) in reply to sebbb
    sebbb:
    "bGroup = (bGroup1 != 0);"

    This line is C, not? Isn't in VB "<>", not "!="? Then, maybe (not VB):

    bGroup = (bGroup1<3) ? (bGroup1 != 0) : bGroup;

    And how is this an improvement? It does the same thing, with the added advantage of requiring a half-second of additional mental 'parsing' time?

  • (cs) in reply to OhDear
    OhDear:
    A perfect example was when a single x+=1 had to be replaced with x=x+1. Why the first wouldn't work where it was while the second worked fine made no sense, but it made the code function. I can see someone following me and thinking that I was a dolt.

    You were a dolt, but only for not understanding the syntax of the language you were working in. <g>

    VB prior to .NET (not sure about VB.NET changing this) doesn't support the operation-assignment syntax. If you want to be able to use that, use a language that includes it; some of those are C/C++, Java, Clipper, etc.

    I doubt anybody that saw it after you wrote it that way thought you were a dolt, however, because they probably knew that VB didn't support the += operation-assignment, and that 'x = x + 1' was indeed the proper way to do it.

  • JohnFx (unregistered) in reply to OhDear
    OhDear:
    Some of that code slightly makes sense. I have used old VB and ended up writing some pretty stupid looking code to get around some very stupid language "features".

    A perfect example was when a single x+=1 had to be replaced with x=x+1. Why the first wouldn't work where it was while the second worked fine made no sense, but it made the code function. I can see someone following me and thinking that I was a dolt.

    Do tell, which of these examples even SLIGHTLY makes sense or looks like a workaround for language "features"?

  • (cs) in reply to BadFellas.org
    BadFellas.org:
    I'm not really familiar with VB.net, so can anyone explain what's wrong with "How to execute a „complicated“ SQL in a stored procedure? Piece of cake!"?
    ...The quotation marks around “complicated”?
  • Beldar the Phantom Replier (unregistered) in reply to Virtually Brillant

    TRWTF is variants - the "= True" part will only succeed if "True" has been assigned to the variant bGroup.

    Virtually Brillant:
    > If bGroup = True Then

    Just that line is enough to make me want to slap the developer with a wet haddock. To be really sure bGroup (presumably a Boolean) is true, why not If (bGroup = True) = True Then or If ((bGroup = True) = True) = True Then or (continue ad nauseam)

    Turn in your geek card, and slap yourself with a wet haddock.

    Option Explicit

    Private Sub Form_Load()
Dim bGroup As Variant
Dim str As String
Dim l As Long
Dim n As Integer
Dim b As Boolean
Dim d As Double
    

    str = "test"
l = 12345
n = 42
d = 3.1415
b = True
    

    Debug.Print ("bGroup: Empty")
Test0 bGroup
Test1 bGroup
Debug.Print ""
    

    bGroup = str
Debug.Print ("bGroup: String - '" & bGroup & "'")
Test0 bGroup
Test1 bGroup
Debug.Print ""
    

    bGroup = l
Debug.Print ("bGroup: Long - " & bGroup)
Test0 bGroup
Test1 bGroup
Debug.Print ""
    

    bGroup = n
Debug.Print ("bGroup: Integer - " & bGroup)
Test0 bGroup
Test1 bGroup
Debug.Print ""
    

    bGroup = b
Debug.Print ("bGroup: Boolean -  " & bGroup)
Test0 bGroup
Test1 bGroup
Debug.Print ""
    

    bGroup = d
Debug.Print ("bGroup: Double - " & bGroup)
Test0 bGroup
Test1 bGroup
Debug.Print ""
    

    Me.Hide
Unload Me
End Sub
    

    Private Sub Test0(val As Variant)
Dim strMsg As String
On Error GoTo Err
strMsg = "Test0 "
If (True = val) Then strMsg = strMsg & "Pass"
    

    Err:
If (0 <> Err.Number) Then strMsg = "Test0 - Error: " & Err.Number & vbTab & Err.Description
Debug.Print strMsg
End Sub
    

    Private Sub Test1(val As Variant)
Dim strMsg As String
On Error GoTo Err
strMsg = "Test1 "
If (val) Then strMsg = strMsg & "Pass"
    

    Err:
If (0 <> Err.Number) Then strMsg = "Test1 - Error: " & Err.Number & vbTab & Err.Description
Debug.Print strMsg
End Sub
  • (cs) in reply to Welbog
    Welbog:
    This article was posted nine years ago for VBScript. I'm talking about a different POS language: VB 2008.

    FTFY.

  • JohnFx (unregistered) in reply to Kozz
    Kozz:
    If bGroup1 = 0 Then
  bGroup = False
ElseIf bGroup1 = 1 Then
  bGroup = True
ElseIf bGroup1 = 2 Then
  bGroup = True
EndIf
    Clearly my brain is not yet sufficiently caffeinated this morning (or it's my lack of VB?). What's the major fault here?

    captcha: paratus (latin, "ready"). I must not be ready to read WTFs yet today?

    Here are the problems (in no particular order): A) bGroup1 (bad variable naming choice)

    B) Values of bGroup1 other than 0,1,2 are not handled, but maybe that isn't so bad (See part C)

    C) Assuming the hungarian notation is used properly, bGroup1 is a boolean type. Comparing it to 0 or 1 is almost forgiveable (but strange in VB), but comparing it to 2?

    D) It could be written a lot more tersely and in a way that is MUCH easier to follow. For example the entire block could have been written as: bGroup = (bGroup1=1 or bGroup1=2)

  • Mad (from plaouf.over-blog.com) (unregistered)

    I think... this wtf... might... have been submitted... by William... Shatner.

  • (cs) in reply to Ken
    Ken:
    How do people fall for this every day?

    Because you end up with new people here who have no idea of what has transpired in the time before they arrived, and they jump right in posting to show off how smart they are.

    Of course, they don't realize that they're not smart at all, as sebbb so brillantly demonstrated. By jumping into a post made by everyone's favorite troll and correcting him, he didn't realize he had just shown people how smart he's not.

    Perhaps sebbb will be smart enough, however, to learn from his mistake and to STFU until he knows the forums and people here better.

  • Stalker (unregistered) in reply to JohnFx
    JohnFx:
    C) Assuming the hungarian notation is used properly, bGroup1 is a boolean type. Comparing it to 0 or 1 is almost forgiveable (but strange in VB), but comparing it to 2?
    Actually, 1 is equally strange since the numerical representation of True is -1.
    JohnFx:
    D) It could be written a lot more tersely and in a way that is MUCH easier to follow. For example the entire block could have been written as: bGroup = (bGroup1=1 or bGroup1=2)
    bGroup1 = 3 and then run the block.
  • Edward Royce (unregistered) in reply to spamcourt
    spamcourt:
    "More JavaScript. Is it a string or an integer?" if (obj.value>="9000" && obj.value<=9999)

    Vegeta, what does the scouter say about his level? IT'S OVER NINE THOUSAND!!!!!

    The scouter is saying "File Not Found" for some damn reason!

  • (cs) in reply to JohnFx
    Here are the problems (in no particular order): A) bGroup1 (bad variable naming choice)
    How do you know? Without context, for all we know is that it refers to "the first grouping", in which case it could make sense. "b" could represent "byte". (Okay, that last is a stretch...)
    B) Values of bGroup1 other than 0,1,2 are not handled, but maybe that isn't so bad (See part C)
    Which could be by design, ie if not 0,1,2 keep the bGroup value as is.
    C) Assuming the hungarian notation is used properly, bGroup1 is a boolean type. Comparing it to 0 or 1 is almost forgiveable (but strange in VB), but comparing it to 2?
    Yeah, this is just silly.
    D) It could be written a lot more tersely and in a way that is MUCH easier to follow. For example the entire block could have been written as: bGroup = (bGroup1=1 or bGroup1=2)
    And that would break it, if they wanted bGroup to remain unchanged if bGroup1 > 2.
  • Viet (unregistered)

    It must be frustrating to use the = as a comparison operator and assignment operator in the same block of code.

  • sebbb (unregistered) in reply to campkev
    campkev:
    sebbb:
    "bGroup = (bGroup1 != 0);"

    This line is C, not? Isn't in VB "<>", not "!="? Then, maybe (not VB):

    bGroup = (bGroup1<3) ? (bGroup1 != 0) : bGroup;

    you are making the assumption that bGroup1 can't be negative

    // assume that true==1 and stuff
assert (true==1);
assert (false==1);
assert ((!!2)==1);
assert ((!2)==0);
assert (2==2); // for the days of apocaliypse

bGroup = (!bGroup1 | !(bGroup1-1) | !(bGroup1-2) ? (!bGroup1) : bGroup;

    Optimized!

  • sebbb (unregistered) in reply to thePowerOfGrayskull
    thePowerOfGrayskull:
    sebbb:
    "bGroup = (bGroup1 != 0);"

    This line is C, not? Isn't in VB "<>", not "!="? Then, maybe (not VB):

    bGroup = (bGroup1<3) ? (bGroup1 != 0) : bGroup;

    And how is this an improvement? It does the same thing, with the added advantage of requiring a half-second of additional mental 'parsing' time?

    I was assuming that bGroup1 is maybe a Nullable type ("undefined"). Of course it's not a real improvement, I was just working around the previous statement, without giving it up, which is not really a good idea.

    And ppl, pardon for feeding the troll I did not see :|

  • (cs)

    Maybe the original developer didn't have access to edit the queries? Maybe somehow there were hundreds of thousands of encrypted files that included different versions of "WHERE AND" logic? Maybe there's... Nevermind, there's no excuse.

  • (cs) in reply to sebbb
    sebbb:
    // assume that true==1 and stuff
assert (true==1);
assert (false==1);
assert ((!!2)==1);
assert ((!2)==0);
assert (2==2); // for the days of apocaliypse

    bGroup = (!bGroup1 | !(bGroup1-1) | !(bGroup1-2) ?
(!bGroup1) : bGroup;

    Optimized!

    The apocalypse has arrived; now what do you?

  • car912 (unregistered) in reply to parris
    parris:
    Maybe the original developer didn't have access to edit the queries? Maybe somehow there were hundreds of thousands of encrypted files that included different versions of "WHERE AND" logic? Maybe there's... Nevermind, there's no excuse.

    I'm thinking it's a lazy correction for code like this:

    if condition1 then
	query=query&" AND blah1='1'"
end if
if condition2 then
	query=query&" AND blah2='something'"
end if
if condition3 then
	query=query&" AND blah3='etc'"
end if
  • Zach Bora (unregistered) in reply to spamcourt
    spamcourt:
    "More JavaScript. Is it a string or an integer?" if (obj.value>="9000" && obj.value<=9999)

    Vegeta, what does the scouter say about his level? IT'S OVER NINE THOUSAND!!!!!

    IT'S OVER NaN!!!

  • BK (unregistered)

    This is one real WTF

  • ShatteredArm (unregistered) in reply to campkev
    campkev:

    if you really are being serious, why would you do this:

    DECLARE @QUERY AS VARCHAR(1000)
    

    SET @QUERY = 'SELECT NUMTASK, YEARTASK, DATEOPEN '
SET @QUERY = @QUERY + 'from TaskStudio '
SET @QUERY = @QUERY + 'WHERE ( '
SET @QUERY = @QUERY + 'CODCOMPANY = ' + CONVERT(VARCHAR,@CODCOMPANY) + ' AND '
SET @QUERY = @QUERY + 'DATEOPENINGS = ''' + CONVERT(VARCHAR,(CONVERT(DATETIME,@ DATEOPENINGS,103))) + ''' AND '
SET @QUERY = @QUERY + 'CODCLIENT = ' + CONVERT(VARCHAR,@CODCLIENT) + ' AND '
SET @QUERY = @QUERY + 'OFFEREURO = ' + CONVERT(VARCHAR,@OFFEREUROVAR)
SET @QUERY = @QUERY + ' ) '
    

    PRINT (@QUERY)
EXEC (@QUERY)

    instead of this

    SELECT NUMTASK, YEARTASK, DATEOPEN 
from TaskStudio 
WHERE ( 
CODCOMPANY = @CODCOMPANY AND 
DATEOPENINGS =  CONVERT(VARCHAR,(CONVERT(DATETIME,@ DATEOPENINGS,103))) AND 
CODCLIENT = @CODCLIENT AND 
OFFEREURO = @OFFEREUROVAR
 )

    Not to mention stored procedures are compiled, thereby improving performance. That the dynamic sql would be compiled, however, seems doubtful. The only reasonable use of dynamic sql inside a stored procedure that I've seen is a stored proc that conditionally connects to different databases, but even if you're doing that, it seems likely that there is a better architectural solution to that problem.

  • Leroy (unregistered)

    Leeroy Jenkins!!!

  • Bob (unregistered)

    THE obj.value IS OVER 9000!!!!!

  • (cs) in reply to TopCod3r
    TopCod3r:
    ElseIf bGroup1 = 1 Then
  bGroup = True
ElseIf bGroup1 = 2 Then
  bGroup = True
    Actually he's on the right track. I require my team to separately enumerate each possible value, even if there are 50 or more.
    1. You can generate the lines of code with a simple script.
    2. It forces you to think about -- and document -- every possibility, and clearly shows the next coder which cases you aren't prepared to handle.
    3. If the requirements suddenly change for, say, bGroup1 = 37, you can go right to that case and update it without damaging the structure of the surrounding code.
    4. The compiler will optimize it all anyway. Better than you can.

    Wait, what? I didn't post this. Nice try.

  • SomeCoder (unregistered) in reply to ShatteredArm
    ShatteredArm:

    Not to mention stored procedures are compiled, thereby improving performance. That the dynamic sql would be compiled, however, seems doubtful. The only reasonable use of dynamic sql inside a stored procedure that I've seen is a stored proc that conditionally connects to different databases, but even if you're doing that, it seems likely that there is a better architectural solution to that problem.

    The other time I've seen dynamic SQL in a stored proc was when the query had to conditionally run on different TABLES.

    Given this very, very poorly designed scenario, is there any other way to do it? I mean besides shooting the guy who designed the database and starting over.

  • Tobidope (unregistered) in reply to Kozz 
    bGroup = (bGroup1 > 0)

    would be to easy?

  • some coder (unregistered) in reply to SomeCoder

    So I have the following, a list of tables, a list of fields that are displayed for each table, predefined queries from the UI how do I handle this?

    The list of tables is not the same from user to user, nor the list of fields. The list of tables changes, and the list of fields changes. The user can choose a few different where clauses. How do I do this without dynamic sql?

  • (cs) in reply to some coder
    some coder:
    So I have the following, a list of tables, a list of fields that are displayed for each table, predefined queries from the UI how do I handle this?

    The list of tables is not the same from user to user, nor the list of fields. The list of tables changes, and the list of fields changes. The user can choose a few different where clauses. How do I do this without dynamic sql?

    Fire your architect and get someone that knows how to design a database.

  • C. F. Martin (unregistered) in reply to TopCod3r
    TopCod3r:
    ElseIf bGroup1 = 1 Then
  bGroup = True
ElseIf bGroup1 = 2 Then
  bGroup = True
    Actually he's on the right track. I require my team to separately enumerate each possible value, even if there are 50 or more.
    1. You can generate the lines of code with a simple script.
    2. It forces you to think about -- and document -- every possibility, and clearly shows the next coder which cases you aren't prepared to handle.
    3. If the requirements suddenly change for, say, bGroup1 = 37, you can go right to that case and update it without damaging the structure of the surrounding code.
    4. The compiler will optimize it all anyway. Better than you can.

    I agree! I always code with my business analysts (who also do the QA work) in mind. They want to make sure that we've covered as many bases as possible including ones that no-one has asked for or even though of. This keeps us all on out toes but its worth it since we are hardly ever get caught off guard by feature creep. Our development meetings can last hours as we try to figure out what our user's requirements might be under all kinds of scenarios.

    We are also endeavoring to write a table driven code generation application that can assist us in this. The tables and code generation bits are driven by various configuration files; we just start a new one when the one we are currently using becomes too big). We hope to build this to a point where we can write applications using hand written client requests that we scan or photograph.

    Captcha = facilisi (Something easy to do in Italy)

  • drach (unregistered) in reply to Sven
    Sven:
    If sCompanyGroup = "" Then
  Field46 = ""
Else
  Field46 = sCompanyGroup
End If
    This one might not be as stupid as it seems. In VB, the comparison somestring = "" evaluates true if the string is empty or if it's Nothing (null for non-VB coders). Comparing to an empty string in VB is equivalent to calling String.IsNullOrEmpty().

    Therefore the above code prevents assigning Nothing (null) to the field.

    Then might I suggest this: Field46 = sCompanyGroup & "" 'or whatever the concant op is

  • (cs) in reply to TopCod3r
    TopCod3r:
    TopCod3r:
    [code]

    Wait, what? I didn't post this. Nice try.

    It must have been one of your team. You taught them well.

  • Izzy (unregistered)

    The complicated SQL query is missing a few essential lines:

    PRINT (@QUERY)
FAX (@QUERY)
PHOTOGRAPHONAWOODENTABLE( (@QUERY)
SCAN (@QUERY)
EXEC (@QUERY)
  • Izzy (unregistered) in reply to Izzy
    Izzy:
    The complicated SQL query is missing a few essential lines: 
    PRINT (@QUERY)
FAX (@QUERY)
PHOTOGRAPHONAWOODENTABLE( (@QUERY)
SCAN (@QUERY)
EXEC (@QUERY)
    Someday I'll learn to count my parens.
  • Robert S. Robbins (unregistered)

    I think I'm guilty of creating a function with too many parameters where a class would have been a better choice. My function requires 13 parameters and returns a structure in order to return 6 variables. Not only that, I set the value of 2 session variables that didn't fit in my structure.

  • Krenn (unregistered) in reply to OhDear
    OhDear:
    Actually += is part of vb.net. I literally just tested it.

    However, it's not in VBA. I attempted it as recently as last week (at least in Office 2003; YMMV for Office 2007 but I doubt it works there either). That's probably more likely than VB6, at least.

  • bb (unregistered) in reply to Stalker

    Actually in VB you False is defined as 0 and True is non-zero.

    So the code could even be easier...

    bGroup = bGroup1

  • bb (unregistered) in reply to bb
    bb:
    Actually in VB you False is defined as 0 and True is non-zero.

    So the code could even be easier...

    bGroup = bGroup1

    Woops I meant "in VB False" and probably since it's a var you should really force that value to boolean, well then nevermind...

  • Walk a mile in my shoes (unregistered)

    I found this article via an English Grammar and Punctuation WTF web site... where it was the WTF of the day... for its abuse... of the ellipse...

  • TimmyT (unregistered) in reply to Krenn
    Krenn:
    OhDear:
    Actually += is part of vb.net. I literally just tested it.

    However, it's not in VBA. I attempted it as recently as last week (at least in Office 2003; YMMV for Office 2007 but I doubt it works there either). That's probably more likely than VB6, at least.

    += and similar shortcuts were implemented in .NET 2.0 (VS2005), along with a lot of other improvements that makes VB pretty robust (yeah, I said it). But back in the old days, x = x + 1 was the way you had to do it.

    Assignment and comparison is still the same (=) but it's always perfectly clear which is which, at least to me. If it's used in a logical statement (if, case, etc.) it will never assign a value. Why would you ever want to assign a value in a logical comparison anyway? if(x=0) print('WTF?');

    BTW before you flame me for being a VB lover, I can code in C# just as well...but Intellisense is better in VB which makes coding in VB faster.

  • TimmyT (unregistered) in reply to sebbb
    sebbb:
    TopCoder: "3. If the requirements suddenly change for, say, bGroup1 = 37, you can go right to that case and update it without damaging the structure of the surrounding code. "

    So it is hard in your team to change something like

    <boohoo surrounding code wtf> if (1 == bGroup1 && 2 == bGroup1) { } <zomg more surrounding code>

    to

    <boohoo surrounding code wtf> if (1 == bGroup1) { } else if (2 == bGroup1) { } <zomg more surrounding code>

    ?

    In professional engineering there is also the paradigm to do work only when it has to be done.

    It is another thing if you have a switch on some enum, because the compiler will be able to warn you if you forgot an enum-case (which saved my arse several times when I was writing parsers), but that's another story.

    Ha ha sucker, you just got TopCod3d! I hope he's back to stay!

  • (cs) in reply to Welbog
    Welbog:
    So it looks like the = operator for comparing strings is horribly broken in VB.

    Hey — it works as documented, that means it's not broken.

  • (cs) in reply to TimmyT
    TimmyT:
    += and similar shortcuts were implemented in .NET 2.0 (VS2005)

    Nope: 1.1 & 2003, respectively.

  • (cs) in reply to JohnFx
    JohnFx:
    Kozz:
    If bGroup1 = 0 Then
  bGroup = False
ElseIf bGroup1 = 1 Then
  bGroup = True
ElseIf bGroup1 = 2 Then
  bGroup = True
EndIf
    Clearly my brain is not yet sufficiently caffeinated this morning (or it's my lack of VB?). What's the major fault here?

    captcha: paratus (latin, "ready"). I must not be ready to read WTFs yet today?

    C) Assuming the hungarian notation is used properly, bGroup1 is a boolean type. Comparing it to 0 or 1 is almost forgiveable (but strange in VB), but comparing it to 2?

    Assume nothing. It is not hungarian notation. Well, if it is hungarian notation, the 'b' doesn't stand for 'boolean'.

    ;)

  • (cs) in reply to Tobidope
    bGroup = (bGroup1 > 0)

    would be to easy?

    First of all, it's TOO not TO and second, for the third time, that is not doing the same thing that the function does.

    When did everyone around here become terrible programmers.

  • NotARobot (unregistered) in reply to TopCod3r
    TopCod3r:
    ElseIf bGroup1 = 1 Then
  bGroup = True
ElseIf bGroup1 = 2 Then
  bGroup = True
    Actually he's on the right track. I require my team to separately enumerate each possible value, even if there are 50 or more.

    It's always worked well for me, but it seems to be taking FOREVER to handle this Double variable!

Leave a comment on “A Touch of Genius”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article