• Anonymous (unregistered)

    I've got one word for this: RAPTORS!

    [image]
  • anon (unregistered) in reply to quibus
    quibus:
    Chelloveck:
    dwb_eng() is a very clear mnemonic. It refers to the author, a DWeeB_ENGineer.
    +1

    you're not supposed to upvote your own posts!

  • Matt Westwood (unregistered) in reply to ochrist
    ochrist:
    moogletrop:
    Earlier than 1983?! You make me feel so young! :-P

    Data? Rewind tape? (remember rewinding and adjusting the volume?!)

    Actually my first programs were written on a TI59 around 1978 and a bit later some version of BASIC (on a technical school via acoustic modem).

    But yeah, I remember all that tape stuff. Actually my old BBC model B is still working but packed away somewhere. Thought about getting rid of it last year, but didn't do it (probably for nostalgic reasons). No tapes, but I still have some 5 1/4" disks somewhere...

    Reckon those things may be worth a bundle by now? Mine is still with me as well. 5 1/4" floppies and all.

  • Marc (unregistered)

    Man, this sucks! When we'll have developers instead of programmers?

  • davi (unregistered)

    The almighty GoTo...

  • Dr. Johnson (unregistered) in reply to Marc
    Marc:
    When we'll have developers instead of programmers?
    When we'll have literates instead of illiterates?
  • Stickman (unregistered)

    I love how all the trackbacks have Acai Berries and various other spam messages in them.

    "Hey, check out this article about the guy who came up with our marketing campaign!"

  • hoodaticus (unregistered) in reply to Maurits
    Maurits:
    hoodaticus:
    The MAZZTer:
    Sub dwb_eng()
        ActiveSheet.Unprotect
        ActiveSheet.Shapes("Option Button 22").Visible = Range("a!Q7").Value * True
        ActiveSheet.Protect
    End Sub

    The slightly-less WTF version. Might not need that * True, not sure, haven't done BASIC in a while.

    VBA was written in C/C++, so True for it is just 1. Which does nothing.

    Actually True is 0xffffffff. And is &. Or is |.

    Really? Go to VBA and do CInt(True + True).

  • hoodaticus (unregistered) in reply to A Gould
    A Gould:
    validus:
    If anyone uses GOTOs in new code, they should be shot. On the other hand, I don't mind maintaining legacy code that is as easy to read as this sample.

    Well, VBA requires GoTos to some extent for error handling ("On Error GoTo [label]"), but that's the only place I'd ever think of using it.

    As for the VB haters, while I'll happily agree that it's not my favorite language (I'd rather be working in one of the three or four other languages I know), it does have one undeniable advantage - it's baked in to Office, which makes it an easy choice when you need a smarter Excel sheet. And since the user still sees Excel, you don't get that "I don't want to learn something" pushback.

    You don't need VBA to script Excel. It has a C API and COM interfaces.

  • hoodaticus (unregistered) in reply to Nome de Plume
    Nome de Plume:
    Gary:
    Uh, even VB can handle this easy to understand oneliner. Hate the = for both comparison and assignment but what can you do?

    ActiveSheet.Shapes("Option Button 22").Visible = (Range("a!Q7").Value=1)

    TRWTF lies thoroughly with the developers for not understanding even the most basic patterns of the language.

    I dislike the sound "to" for both two (2) and too (also). Yet, I can always tell them apart by parsing the grammar!

    In VB flavors, you can only assign to the memory location identified at the beginning of the line. In C flavors, you can assign anywhere. You'll never see this in VB:
    ddlMyList.Enabled=(chkDisableMyList.Checked=False);
    Or rather, if you did have that in VB, it would mean:
    ddlMyList.Enabled=(chkDisableMyList.Checked==False)
    which is completely different.

  • Luiz Felipe (unregistered)

    Visual Basic (for application) is COM enabled, why take so much more pain only because you hate the sintax. or perhaps you dont like to redistribute vba, it alread comes with excel, so, same diference. The true coder dont care what language is it, he will use correct tool for the job and done with it. Only noob think that all must be done in one language. that one language rule them all. if its true, then what is the purpose of a broad range of languagues. If you dont like excel at all, you can make some xml in format that it reads, its open standard.

    Sorry my poor english, i am self taughting.

  • WyrdWyrd (unregistered) in reply to uxor
    uxor:
    moogletrop:
    Line numbers? Are they mad? Surely labels are the way forward?
    VBA uses labels, so those aren't really line numbers, they are numeric labels.

    Actually, in VBA, the line labels end with a colon and appear on a line by themselves.

  • WyrdWyrd (unregistered)

    Let's re-write it: Sub dwb_eng() ActiveSheet.Unprotect ActiveSheet.Shapes("Option Button 22").Visible = ( Range("a!Q7").Value = 1 ) ActiveSheet.Protect End Sub [/code]

    I'm not sure if you can do a truth value assignment in that way in VBA but I think so.

    Furry cows moo and decompress.

  • John Muller (unregistered)

    GOTO is fine by me. Even COMEFROM can be worked out.

    For true insanity, consider this: "Calculated Goto"

    Aeons ago, I did something like this to the user input from a multi-level menu, for my self-written dial-up BBS.

    666 GOTO (10000+B11000+B2100+B3*10)

    10000 PRINT "Draw Main Menu" 11000 PRINT "Draw a sub Menu" 12000 PRINT "Draw Messaging menu" 12300 PRINT "Draw Post a new message menu" 12310 PRINT "Posting a new Public message" 12320 PRINT "Posting a new Private message" 19000 PRINT "Logging Off"

    And yes, I did take advantage of 'fall through' all message types would drop into common code; as well as more than 10 options on a menu, so '13000' could be (3,0,0) or (2,10,0).

    Nowdays, whenever I think I did something really clever in my code; I stop and rewrite it in a simpler form.

  • Valcon (unregistered)

    There isn't anything wrong with using VBA for the right purposes, like macro's to make life more tolerable when using Excel or Word. Unfortunately, VBA is being used to build complex LOB applications, using thousands of lines of code.

    To use an analogy: Lego is great for building very small (few inches or so) houses. But every sane person would probably agree it is not fit to build a real-size house. Unless you're James May (http://www.jaboo.nl/2009/09/james-mays-lego-house/). I think of VBA as Lego: great for doing stuff on a small scale.

  • DC (unregistered) in reply to PleaseStopWritingCode
    PleaseStopWritingCode:
    DC:
    A Gould:
    Well, VBA requires GoTos to some extent for error handling ("On Error GoTo [label]"), but that's the only place I'd ever think of using it.

    Actually, no it doesn't. You use 'On Error Resume Next' instead, and test for the error inline.

    Not quite Try..Catch but it sure beats those stupid GoTo error blocks.

    If you're trying to emulate try..catch in VB then "On Error Goto <label>" is much closer than "On Error Resume Next"!

    I hope your boss doesn't see what you wrote!

    I hope your boss reads your comment, someone who thinks a try..catch means randomly jumping to the end of a procedure (for ANY error), doing something, and then exiting or randomly jumping back shouldn't be coding.

    You should be doing this:

    On Error Resume Next A = B / 0 'oh no! If Err Then 'it broke Else 'no it didn't End If 'right then, carry on. Err.Clear On Error Goto 0

    An alternate, cleaner version:

    On Error Resume Next A = B / 0 'oh no! LastErr = Err Err.Clear On Error Goto 0 If LastErr Then 'it broke Else 'no it didn't End If 'right then, carry on.

    That's inline error handling. I suspect you didn't know VB could do that. Now you do.

    I showed my boss. He laughed at you. I'm fixing some other losers code, which is full of, you guessed it, something that you would do.

  • PleaseStopWritingCode (unregistered) in reply to DC
    DC:
    PleaseStopWritingCode:
    DC:
    A Gould:
    Well, VBA requires GoTos to some extent for error handling ("On Error GoTo [label]"), but that's the only place I'd ever think of using it.

    Actually, no it doesn't. You use 'On Error Resume Next' instead, and test for the error inline.

    Not quite Try..Catch but it sure beats those stupid GoTo error blocks.

    If you're trying to emulate try..catch in VB then "On Error Goto <label>" is much closer than "On Error Resume Next"!

    I hope your boss doesn't see what you wrote!

    I hope your boss reads your comment, someone who thinks a try..catch means randomly jumping to the end of a procedure (for ANY error), doing something, and then exiting or randomly jumping back shouldn't be coding.

    You should be doing this:

    On Error Resume Next A = B / 0 'oh no! If Err Then 'it broke Else 'no it didn't End If 'right then, carry on. Err.Clear On Error Goto 0

    An alternate, cleaner version:

    On Error Resume Next A = B / 0 'oh no! LastErr = Err Err.Clear On Error Goto 0 If LastErr Then 'it broke Else 'no it didn't End If 'right then, carry on.

    That's inline error handling. I suspect you didn't know VB could do that. Now you do.

    I showed my boss. He laughed at you. I'm fixing some other losers code, which is full of, you guessed it, something that you would do.

    Are we supposed to be surprised that you're employed by someone who is as bad at coding as you are?

  • PleaseStopWritingCode (unregistered) in reply to PleaseStopWritingCode
    PleaseStopWritingCode:
    DC:
    PleaseStopWritingCode:
    DC:
    A Gould:
    Well, VBA requires GoTos to some extent for error handling ("On Error GoTo [label]"), but that's the only place I'd ever think of using it.

    Actually, no it doesn't. You use 'On Error Resume Next' instead, and test for the error inline.

    Not quite Try..Catch but it sure beats those stupid GoTo error blocks.

    If you're trying to emulate try..catch in VB then "On Error Goto <label>" is much closer than "On Error Resume Next"!

    I hope your boss doesn't see what you wrote!

    I hope your boss reads your comment, someone who thinks a try..catch means randomly jumping to the end of a procedure (for ANY error), doing something, and then exiting or randomly jumping back shouldn't be coding.

    You should be doing this:

    On Error Resume Next A = B / 0 'oh no! If Err Then 'it broke Else 'no it didn't End If 'right then, carry on. Err.Clear On Error Goto 0

    An alternate, cleaner version:

    On Error Resume Next A = B / 0 'oh no! LastErr = Err Err.Clear On Error Goto 0 If LastErr Then 'it broke Else 'no it didn't End If 'right then, carry on.

    That's inline error handling. I suspect you didn't know VB could do that. Now you do.

    I showed my boss. He laughed at you. I'm fixing some other losers code, which is full of, you guessed it, something that you would do.

    Are we supposed to be surprised that you're employed by someone who is as bad at coding as you are?
    Oh, just actually read your code - poor trolling attempt there!

  • Gavin (unregistered)

    The real WTF is that VBA supports a "GoTo" clause in place of the "Then" clause, so saying "Then GoTo" is redundant.

  • (cs) in reply to hoodaticus
    hoodaticus:
    Maurits:
    hoodaticus:
    VBA was written in C/C++, so True for it is just 1. Which does nothing.

    Actually True is 0xffffffff. And is &. Or is |.

    Really? Go to VBA and do CInt(True + True).

    Sub Macro1()
        MsgBox _
            "True * 1 = " & (True * 1) & vbCrLf & _
            "False * 1 = " & (False * 1) & vbCrLf & _
            "True + True = " & (True + True) & vbCrLf & _
            "6 And 5 = " & (6 And 5) & vbCrLf & _
            "5 And 2 = " & (5 And 2) & vbCrLf & _
            ""
    End Sub
    

    Microsoft Excel

    True * 1 = -1

    False * 1 = 0

    True + True = -2

    6 And 5 = 4

    5 And 2 = 0


    OK

  • (cs) in reply to uxor
    uxor:
    moogletrop:
    Line numbers? Are they mad? Surely labels are the way forward?
    VBA uses labels, so those aren't really line numbers, they are numeric labels.

    Are you sure? YBasic for the Palm actually numbers (or at least counts) the lines, so that if you have two lines numbered 100 and 110, and there are more than 9 lines between the numbered lines, then the program won't run (gives a syntax error).

    I haven't had the nerve to try branching to 102 in this case...if it worked, that could lead to a true horror.

  • goto_main_sub3 (unregistered) in reply to modo
    modo:
    There is nothing wrong with using GoTo for an If statement if the language supports it. The sample code is clean and understandable, has a single entry point and a single exit point.

    That said, TRWTF is VBA.

    I hope you are not a programmer, this is for you: http://xkcd.com/292/

  • Not Dorothy (unregistered) in reply to Todd Lewis

    FCS/EPS had (has?) this feature. Each line of code was written against a row in a table (like a spreadsheet) and you could

    500 CALC(300. , 310.)

    Which executed lines 300 to 310. But note the use of the decimal point here.

    500 CALC(300 , 310)

    Would take the value held in column 1 of row 300 and use that as the line number to execute from. And would use the value held in column 1 of row 310 as the last row to execute. So

    300 = 120. 310 = 400. 500 CALC(300 , 310)

    Would execute lines 120 to 400. Now guess what the following would do...

    500 CALC("300" , "310")

    Yes that is a double indirect!

    120 = 1000. 300 = 120. 310 = 400. 400 = 1200. 500 CALC("300" , "310")

    Would execute lines 1000 to 1200.

    Basic was sane in comparison :(

  • (cs)

    I also learned BBC basic (having waited a year or more so we could afford it while others got their ZX81s and Spectrums!)

    From memory there was a real emphesis in magazine articles on avoiding GOTO and GOSUB in favour of REPEAT UNTIL and PROC or FN. I still don't like having to use them for error handling now. Certainly the language was much closer to PASCAL than other BASICs out there at the time.

    As for VBA, it isn't the language that makes bad code, just the fact that almost every user has it on their desktop and thus can start writing it. I'm sure the authors of most of the VBA WTFs could create plentty more in any other language they had available and it would be just as grim.0

    If you want a really scary language it was Lotus 1-2-3 macros where the instructions were stored in worksheet cells and thus you often saw self-modifying code.

  • PleaseStopWritingCode (unregistered) in reply to Risky
    Risky:
    As for VBA, it isn't the language that makes bad code, just the fact that almost every user has it on their desktop and thus can start writing it. I'm sure the authors of most of the VBA WTFs could create plentty more in any other language they had available and it would be just as grim.

    ^this++

    A bad coder will write bad code in any language, some people's brains just aren't wired-up to be programmers.

    If you can't write decent code in VB then I'd suggest programming probably isn't the career for you, at the very least if VB can't do what you need you should be able to recognise that fact and switch to something that can - that's what real programmers do.

  • Anonymous (unregistered) in reply to Risky
    Risky:
    As for VBA, it isn't the language that makes bad code, just the fact that almost every user has it on their desktop and thus can start writing it.
    Yes, we all understand perfectly well that bad coders will write bad code in any language. It doesn't change the fact that a language with poor syntax (who needs line terminators?) and bad paradigms (who needs type safety?) severely exacerbates the situation. I guess what I'm trying to say, in summary, is that VB(A) is TRWTF.
  • (cs) in reply to Anonymous
    Anonymous:
    Yes, we all understand perfectly well that bad coders will write bad code in any language. It doesn't change the fact that a language with poor syntax (who needs line terminators?) and bad paradigms (who needs type safety?) severely exacerbates the situation.

    Are you talking about VB or JavaScript here? I can't tell.

  • (cs) in reply to Jerry
    Jerry:
    This is why every language with "goto" also needs "camefrom". As in:

    if camefrom = 40 then ... and so on...

    Every BASIC has GOSUB...RETURN for this.
  • (cs) in reply to PleaseStopWritingCode
    PleaseStopWritingCode:
    If you can't write decent code in VB then I'd suggest programming probably isn't the career for you...
    Your good advice will fall on deaf ears: lousy programmers aren't typically able to distinguish between decent and lousy code, especially if they wrote it.
    PleaseStopWritingCode:
    ...at the very least if VB can't do what you need you should be able to recognise that fact and switch to something that can - that's what real programmers do.
    On the other hand, lousy programmers can get VB to do what they want. In fact, they manage to do so all the time; they just have to write a bunch of lousy code to do it.

    Therefore, I think you should revise your guideline: If you can get VB to do what you want, you must be writing lousy code and should not be a programmer.

    Disclaimer: Yes, I'm kidding. Or am I?

  • DC (unregistered) in reply to PleaseStopWritingCode
    PleaseStopWritingCode:
    Are we supposed to be surprised that you're employed by someone who is as bad at coding as you are?

    I get paid suprising well for it too. Learning Excel was the best thing I ever did, guess who the hot chicks call to fix their little spreadsheets?

    Anyway, you've seen mine, let's see yours. Amaze up with your brilliance, MrI'mNotQuiteSureHowTry..CatchWorks.

  • Marshall (unregistered) in reply to modo

    It appears that those who ignore the past tend to repeat the same mistakes.

    The original letter by Dijkstra about the foul'ness of using GOTO's is at:

    http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF

  • Marshall (unregistered) in reply to modo

    It appears that those who ignore the past tend to repeat the same mistakes.

    The original letter by Dijkstra about the foul'ness of using GOTO's is at:

    http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF

  • DC (unregistered) in reply to Marshall
    Marshall:
    It appears that those who ignore the past tend to repeat the same mistakes.

    The original letter by Dijkstra about the foul'ness of using GOTO's is at:

    http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF

    Posted twice because you forgot about the first one? Unintended jokes are often the best.

    Speaking of jokes, I see that tool PleaseStopWritingCode, aka MrDoesn'tWriteCodeButJustTalksShit has yet to amaze us with his brilliant method of error handling in VB[A].

    Error handling in VB sucks either you do it, but not doing it sucks even more.

    Not even knowing how, as demonstrated by the afore-mentioned joke, sucks even more if he's the one doing your coding.

  • PleaseStopWritingCode (unregistered) in reply to DC
    DC:
    PleaseStopWritingCode:
    Are we supposed to be surprised that you're employed by someone who is as bad at coding as you are?

    I get paid suprising well for it too. Learning Excel was the best thing I ever did, guess who the hot chicks call to fix their little spreadsheets?

    Anyway, you've seen mine, let's see yours. Amaze up with your brilliance, MrI'mNotQuiteSureHowTry..CatchWorks.

    I'm not here to educate you, if you can't see how to get closer to try...catch in VB for yourself then once again I'd suggest you're perhaps not the best programmer, I'll give you a clue though - it's not the inline error handling that you suggested, good grief it's not like you've got many mechanisms to choose from, Einstein!

    There's not any "brilliance" required, that's why it's amusing that you don't get it!

    Just to satisfy my curiosity, are you by any chance quite young? e.g. under 25? It's just that your attitude smells like an arrogant kid, of course you could lie and tell us that you're 40 or something....meh.

    You appear to be quite irritated though - good.

  • PleaseStopWritingCode (unregistered)

    @DC

    I can't help but picture you as this guy:

    http://www.theregister.co.uk/2008/10/23/sickie_woo/

    Now, how do you picture me, be original now....

  • DC (unregistered) in reply to PleaseStopWritingCode
    PleaseStopWritingCode:
    @DC

    I can't help but picture you as this guy:

    http://www.theregister.co.uk/2008/10/23/sickie_woo/

    Now, how do you picture me, be original now....

    Yes, the manager asking him to prove where he was does sound like me. Well spotted there, 'sickie woo'.

    ...and once again, let's see you post some code, rather than just talk, to show us how you do things.

    You can't code at all, in any language, can you?

  • DC (unregistered) in reply to PleaseStopWritingCode
    PleaseStopWritingCode:
    Just to satisfy my curiosity, are you by any chance quite young? e.g. under 25? It's just that your attitude smells like an arrogant kid, of course you could lie and tell us that you're 40 or something....meh.

    I was thinking the same about you...

    So VB has lots of ways to do error handing, so how do you do it? Oh that's right, you don't know.

    Geez, imagine VB being being to hard.

  • PleaseStopWritingCode (unregistered) in reply to DC
    DC:
    PleaseStopWritingCode:
    Just to satisfy my curiosity, are you by any chance quite young? e.g. under 25? It's just that your attitude smells like an arrogant kid, of course you could lie and tell us that you're 40 or something....meh.

    I was thinking the same about you...

    So VB has lots of ways to do error handing, so how do you do it? Oh that's right, you don't know.

    Geez, imagine VB being being to hard.

    No, VB has a finite number of error handling approaches, you think "on error resume next" is the closest to try...catch........would love to see you're code in a language where try..catch is available, I need another laugh!

    Tell me, are you by any chance an Option Base 1 kinda guy?

    Also, you should try using "too" instead of "to" where appropriate, do you need examples of that, or in this case is the theory enough?

  • PleaseStopWritingCode (unregistered)

    @DC

    As for not posting code, there's a china teapot floating in space, can you see the analogy?

    You, however, have posted code and thus proved your level of ability for everyone to see ;-)

  • A. Cube (unregistered)

    This code has so much "worse than failure" promise that it almost seems a shame that the code sample was so short.

  • DC (unregistered) in reply to PleaseStopWritingCode
    PleaseStopWritingCode:
    DC:
    So VB has lots of ways to do error handing, so how do you do it? Oh that's right, you don't know.

    Geez, imagine VB being being to hard.

    No, VB has a finite number of error handling approaches, you think "on error resume next" is the closest to try...catch........would love to see you're code in a language where try..catch is available, I need another laugh!

    Tell me, are you by any chance an Option Base 1 kinda guy?

    Also, you should try using "too" instead of "to" where appropriate, do you need examples of that, or in this case is the theory enough?

    You can type all that but can't cough up a few lines of code? What's your excuse, your dog ate it?

    What I said was VB could test for errors inline - and that it wasn't quite try..catch but better than 'On Error Got label'.

    Of course you don't know any of those, being unable to code in any language, VB being all too hard.

    And yes, I know about try..catch from Vb.net, C# & T-SQL.

    But feel free to complain my starting sentences with 'and' & 'but'.

    You're all hat, no horse.

  • DC (unregistered) in reply to A. Cube
    A. Cube:
    This code has so much "worse than failure" promise that it almost seems a shame that the code sample was so short.

    You should see the code that tool 'PleaseStopWritingCode' produces, it's so short it's non-existent. At least he lives up to his name.

  • PleaseStopWritingCode (unregistered) in reply to DC
    DC:
    You can type all that but can't cough up a few lines of code? What's your excuse, your dog ate it?
    I think probably because it's bugging you.
    DC:
    What I said was VB could test for errors inline - and that it wasn't quite try..catch but better than 'On Error Got label'.
    Yep, somebody called A Gould posted something reasonable and you outright said they were incorrect and that your 'special' approach was THE way to mimick try..catch in VB, you didn't explain why though?

    I am suggesting that you are wrong and should reconsider your approach. If you're going to post arrogant dismissive comments and awful code on a site called The Daily WTF you have to expect to get called on it, what kind of people do you think read this site, people who want to help you learn or people who are looking for crap code to laugh at?!

    DC:
    And yes, I know about try..catch from Vb.net, C# & T-SQL.
    Oh noes! I didn't realise I was talking to someone with such depth of knowledge and experience, I am humbled and/or concerned.

    Since you know C# here's a snippet, assume a Windows Forms app:

    try
    {
        throw new System.Exception("Catch me, catch me!");
    }
    catch(System.Exception e)
    {
        System.Windows.Forms.MessageBox.Show(e.ToString());
    }
    finally
    {
       System.Windows.Forms.MessageBox.Show("Do you get it yet?");
    }
    

    Now, here's some VB, please try to emulate the simple example above by adding to the code, points given for providing comments explaining which bit of try..catch you are mimicking, extra points for providing something close to finally.

        Err.Raise Number := vbObjectError + 1, Description := "Catch me, catch me"
    

    I can hear you Googling from here...

    Disclaimer: I don't have a compiler handy so there might be a typo etc. in the above code, still, shouldn't bother an expert.

  • DC (unregistered) in reply to PleaseStopWritingCode
    PleaseStopWritingCode:
    Yep, somebody called A Gould posted something reasonable and you outright said they were incorrect and that your 'special' approach was THE way to mimick try..catch in VB, you didn't explain why though?

    A Gould, like you, was unaware that VBA supports inline error handling. Not unsurprising as it doesn't get mentioned much.

    It's also unsurprising that you want me to provide the solution, the one you claimed you have. Y'know, educate me, something more than nit-picking a minor typo. Anyway, the answer is already in the thread.

    You're the type of person probationary periods were invented for, you sound like you know things, but are unable to produce.

    Anyway, enough of feeding the trolls. I leave you to your 'victory', enjoy. Feel free to use both hands when celebrating with your penis, although I'm certain you only need one.

  • Steven (unregistered)

    It looks like MIPS...

    Branch if Equal, anyone?

  • PleaseStopWritingCode (unregistered) in reply to DC
    DC:
    PleaseStopWritingCode:
    Yep, somebody called A Gould posted something reasonable and you outright said they were incorrect and that your 'special' approach was THE way to mimick try..catch in VB, you didn't explain why though?

    A Gould, like you, was unaware that VBA supports inline error handling. Not unsurprising as it doesn't get mentioned much.

    Everyone knows that VB supports "inline error handling", only 'special' people would assert that it's the best way to replicate try..catch.

    Just because someone doesn't mention something doesn't mean they don't know about it - I take it the teapot analogy passed straight over your head.

    Resorting to ad hominem attacks is a strong sign of someone who has dug themselves into a hole.

    No victory here, the only 'win' would be you learning to code better.

    In case you do want to improve (don't worry you don't have to admit it) the better approach is all over the Internet - GIYF...it's even in MSDN.

    Part of me still thinks you're a troll, I really can't believe anyone would actually think this way.

  • dgatwood (unregistered) in reply to WyrdWyrd

    Labels make things much more fun. With labels, AFAIK, there's no reason for the numbers to be in order.

    100 if ... then goto 200 else goto 300 300: ... 200 ... 400 ...

  • ewanm89 (unregistered) in reply to anonymous_coder()

    Goto in C?

Leave a comment on “Learning Something New”

Log In or post as a guest

Replying to comment #:

« Return to Article