• (cs) in reply to don
    don:
    numOrd = xOrdNum

    Can you just assign a string to a long like that?


    Yep, it gets worse if you're not careful

    "2" + "2" = "22"
    "2" + 2 = 4

  • (cs) in reply to Jan Hyde

    VB has a Like operator?

    The hell?

  • boland (unregistered) in reply to Diego Barros
    Anonymous:

    Anonymous:
    Coding, I think you mean.

    No, I mean code.

    I'd rather be watching TV than run in a marathon.

    I'd rather be watching TV than running in a marathon.

    I like the prior, not the latter. [:D]

    If it's not 100% grammatically, I don't know. But the numerous people that have seen it have not made that comment. Must not be too bad. Besides, I just prefer it the way it is. [:)]

    I'd rather jack than fleetwood mac

     

  • (cs) in reply to Generic
    Generic:
    Public Function VerifyOrdNum(xOrdNum As String) As Boolean
  If xOrdNum Like "#######" Then
    VerifyOrdNum = True
  Else
    MsgBox "Order # must be seven (7) digits long.", , strErrTitle
    VerifyOrdNum = False
  End If
End Function

    As a long time VB developer and instructor, I would certainly fault the coder for the MsgBox inside the validation routine.  It would be better to pass error messages up through a parameter or return a non-empty string, describing the error, if there were validation problems. (instead of returning a Boolean value)

    What I find curious is the lack of external validation.  Maybe that follows this validation step.  Is this OrderNumber in the database?  Is this an active order number?  Is this user allowed to see this order?

    My validation credo is "The best validation is to prevent the user from entering wrong data."  KeyPress events are a common place to prevent invalid characters or wrongly structured data.  Although more difficult to work with, the masked edit control would help limit the user to numeric digits without doing any coding.  If feasible, I would prefer showing eligible order numbers in a combobox.

    I would generalize the suggested validation a bit, allowing for varying lengths of numeric strings.  In the case of this WTF VerifyOrdNum function, the length would be 7.

    Public Function IsNumericString(xNum As String, xLen As Long) As Boolean
  If xNum Like <FONT color=#000000>String(xLen, "#")</FONT> Then
    IsNumericString = True
  Else
    IsNumericString = False
  End If
End Function
    Public Function VerifyOrdNum(xOrdNum As String) As Boolean
  If IsNumericString(xOrdNum, 7) Then
    VerifyOrdNum = True
  Else
    VerifyOrdNum = False
    MsgBox "Order # must be seven (7) digits long.", , strErrTitle
  End If
End Function
  • Esmo (unregistered)

    I find it ironic that (from what I can tell) there is actually a typo in the description. " After a little while of going through and documenting the code, they were delighted to finally see some a comment..." some a comment? ;)

  • (cs) in reply to A VB user to afraid of language bigots

    A VB user to afraid of language bigots:

    from the Type conversion functions help page...

    When the fractional part is exactly 0.5, CInt and CLng always round it to the nearest even number. For example, 0.5 rounds to 0, and 1.5 rounds to 2. CInt and CLng differ from the Fix and Int functions, which truncate, rather than round, the fractional part of a number. Also, Fix and Int always return a value of the same type as is passed in.

    Geeze, and many of you are critical of so many others.  CInt is doing exactly as designed.  If you want to truncate use Int.

    CInt = Convert a value to an Integer
    CLng = Convert a value to a Long Integer

    If the function is not just converting the data, but also modifying it, then it's not exactly a clean conversion is it? I understand that in the case of decimal numbers being converted to whole numbers, there has to be some kind of change. But why use the obscure bankers rounding?? Maybe change CInt/CLng to have an optional parameter to either round or truncate the number.

  • Some Guy (unregistered)

    Don't know if anyone pointed this out earlier, but would it ever get to the error handling since the assignment (numOrd = xOrdNum) is after the On Error GoTo errorhandler

  • (cs) in reply to A VB user to afraid of language bigots
    Anonymous:
    Gene Wirchenko:
    It get worse.  VB6 uses symmetric rounding.  That means when the amount being rounded is exactly one-half of the unit, it will round towards an even digit.  17.5 is rounded to 18, and 2.5 is rounded to 2.  Symmetric rounding is not a bad thing, as it helps reduce rounding bias, but the VB6 docs do not state what sort of rounding is used, so you can get surprised.

    Try calculating 17.5\2.5 (integer division) for some fun.


    from the Type conversion functions help page...

    When the fractional part is exactly 0.5, CInt and CLng always round it to the nearest even number. For example, 0.5 rounds to 0, and 1.5 rounds to 2. CInt and CLng differ from the Fix and Int functions, which truncate, rather than round, the fractional part of a number. Also, Fix and Int always return a value of the same type as is passed in.

    Geeze, and many of you are critical of so many others.  CInt is doing exactly as designed.  If you want to truncate use Int.


    I did not use either and triggered rounding.

    It might well be performing as designed, but I looked rather hard through the docs for information on how the rounding was done.  I found nothing.  Are you referring to the VB6 docs or something later?

    Sincerely,

    Gene Wirchenko

  • (cs) in reply to Some Guy

    Some Guy:
    Don't know if anyone pointed this out earlier, but would it ever get to the error handling since the assignment (numOrd = xOrdNum) is after the On Error GoTo errorhandler

    It feels kinda dirty to know this much about VB, but...

    When you put in the "On Error" statement, it means from that point in the code until the end of the Sub or Function, don't crash if a run-time error occurs. It's most beneficial to put the statement at the top of your function, but you can put it in the middle as this guy did. It just means that any errors caused by code above this line will crash the program.

  • (cs) in reply to Manni
    Manni:

    Some Guy:
    Don't know if anyone pointed this out earlier, but would it ever get to the error handling since the assignment (numOrd = xOrdNum) is after the On Error GoTo errorhandler

    It feels kinda dirty to know this much about VB, but...

    When you put in the "On Error" statement, it means from that point in the code until the end of the Sub or Function, don't crash if a run-time error occurs. It's most beneficial to put the statement at the top of your function, but you can put it in the middle as this guy did. It just means that any errors caused by code above this line will crash the program.



    Don't feel dirty, sometimes it is good to know about the evil that is called VB.  In fact, I would say that this makes sense, considering that VB is loosley based on a language that you had to specify the line numbers for each and every line of code and was considered good practice to use multiples of 10 so that if you wanted to add a line somewhere, you wouldn't have to re-number everything and wouldn't break existing "GoTo"  statements.

    The best trick that the devil ever played was to convince the world that he doesen't exist.

  • (cs) in reply to Manni
    Manni:
    It feels kinda dirty to know this much about VB, but...


    Ignorance is better?

    When you put in the "On Error" statement, it means from that point in the code until the end of the Sub or Function, don't crash if a run-time error occurs. It's most beneficial to put the statement at the top of your function, but you can put it in the middle as this guy did. It just means that any errors caused by code above this line will crash the program.


    No, it does not.  It mean that that on error statement does not handle it.  There can be other on error statements further up (in calling code).

    Sincerely,

    Gene Wirchenko

  • (cs) in reply to Gene Wirchenko
    Gene Wirchenko:
    Manni:
    It feels kinda dirty to know this much about VB, but...


    Ignorance is better?



    Ignorance is better than feeling kinda dirty?  ummm, yeah! at least sometimes! I'm sure that if you though about it, you would agree.

    <font color="#ff0000"></font>
  • (cs) in reply to TankerJoe
    TankerJoe:
    Gene Wirchenko:
    Manni:
    It feels kinda dirty to know this much about VB, but...


    Ignorance is better?


    Ignorance is better than feeling kinda dirty?  ummm, yeah! at least sometimes! I'm sure that if you though about it, you would agree.


    Well, I do not.  The languages can be useful.  They might not be what you like or can use, but knowing them does not contaminate you.  Not knowing them, but still whining about them makes you a whining ignoramus.  There is a squaring effect there.

    Sincerely,

    Gene Wirchenko

  • (cs) in reply to Gene Wirchenko

    Gene Wirchenko:
    TankerJoe:
    Gene Wirchenko:
    Manni:
    It feels kinda dirty to know this much about VB, but...


    Ignorance is better?


    Ignorance is better than feeling kinda dirty?  ummm, yeah! at least sometimes! I'm sure that if you though about it, you would agree.


    Well, I do not.  The languages can be useful.  They might not be what you like or can use, but knowing them does not contaminate you.  Not knowing them, but still whining about them makes you a whining ignoramus.  There is a squaring effect there.

    Sincerely,

    Gene Wirchenko

    Acctually, you are both right and wrong on this (Ahhh the dichotomy!).  While the languages can be useful, knowing them can contaminate you.  In my case, I had to go back and relearn a lot of foundation type stuff and unlearn some bad/lazy habits when I "upgraded" from VB to Java.  If I had happen to learn Java, C++, or even  Pascal (although pascal is pushing it), first, then I would not have been contaminated with that VB knowledge and life would have been measurably easier for me  .  Truth be told, I was doomed this pain from the start, being my first language at age 11 was "GW-Basic"... ahh, those were the days, line numbers, goto's, good stuff.....

    Anyways, my original point was that "SOMETIMES" ignorance is better than feeling kinda dirty.  Here is my proof:   Your ignorance of what it tastes like to lick my rectum is certainly better than the dirty feeling that both you and I would have in the event that you were able to gain that knowledge.

    As opposed to my original post, please do not think about this too much.  Much more pleasant if you just simply agree.

  • Beau Wilkinson (unregistered) in reply to Jan

    If this works, I don't have a problem with it. In fact, it almost seems (dare I say it?) elegant.

    As far as I can tell, the main risk in using "ON ERROR GOTO" here is that some whiz kid will find your code later on and make fun of it... which seems to be exactly what has happened.

    Not knowing the nuances of VB6, I can't vouch for the proper performance of the code under every single situation, but this does seem like a potential way to ensure the input string consists solely of digits.

    Many people would say it is bad form to use the error handling system for validation. There is more overhead associated with something like try/catch than there is with something like IsNumeric. But IsNumeric() won't work in this situation (a "numeric" is not really what you're checking for); and unless there's a function along the lines of "IsLong" or "IsSequenceOfDigits,", then there may not be a way to check validity without resorting to much more verbose code (e.g. looping through each character).

    And I would not consider it worthwhile to search for "IsLong" or "IsSequenceOfDigits" without a really compelling reason (i.e. unless I could not reasonably make it work otherwise). Yes, there is probably a function somewhere in the relevant libraries that does what's necessary... but it is located and named in the manner of whatever programmer originally developed it, and it will take one quite a while to become as familiar with its name / location as I am with VB casting and error handling (which one would presumably already have mastered.)

    I have worked on several projects where extensive object hierarchies, libraries, custom controls, etc. associated with validation were laboriously developed and promulgated. To me, that is the real WTF (i.e. "who the f_ck," as in "who the f_ck needs to use inheritance and polymorphism to check to see if an input string contains only digits?")

    Is anyone going to flame me for saying this? I am sorry, but I have not spent the better part of my life learning computer programming in order to take its most advanced concepts and apply them to $hit-ass problems like validation and logging. To me, validation and logging fall into the category of "things that can be accomplished using if-then and windows.h."

     

  • Defiler (unregistered)

    Uhh.. doesn't this function always immediately return True, as soon as the assignment on the first line occurs?

  • A chicken passeth by (unregistered) in reply to Defiler

    Not necessarily. Attempting to assign a String to a Long value has a chance of triggering the Data Type Mismatch error. If the string is a number, eebil type casting will bypass this; if it isn't, the resulting exception will be caught by On Error Goto.

    (Tho IIRC when I coded in VB6 SP6 on Option Explicit I needed to CInt/CDouble first before I could do this without getting kicked.)

  • (cs)
    Alex Papadimoulis:

    Public Function VerifyOrdNum(xOrdNum As String) As Boolean
  VerifyOrdNum = True
End Function


    This is the real WTF. The first line of the function makes it so that it always returns TRUE. The obscure code following this statement is never even executed.
  • Belcat (unregistered) in reply to Manni

    Actually, it does something Isnumeric doesn't - it checks if it fits in a long.  In particular,
    ?isnumeric("1234E99")
    True

    would be numeric and 7 digits, but would fail the minute you tried to put it in a long.  My favorite tests were to put "1E99" and break all the developper's code here.

Leave a comment on “Some Basic Error Handling”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article