• RobIII (unregistered) in reply to boohiss

    <FONT face=Arial size=2>

    Anonymous:
    If the string is numeric, the converted (& truncated if decimal) int is returned. If it's not, an exception is thrown (whoops...VB...) it blows up.
    Incorrect. If the string is not numeric, CInt returns a 0.
    </FONT>

    <FONT face=Arial color=#ff0000 size=2> * RobIII fires up VB6 and writes some code...</FONT>

    <FONT face=Arial><FONT size=2><FONT color=#0000ff>Private Sub Form_Load()
        MsgBox CInt("a")
    End Sub</FONT>
    </FONT></FONT>

    <FONT face=Arial><FONT size=2><FONT color=#ff0000> * RobIII hits F5 (Run)....</FONT> <FONT size=5>*BANG*</FONT>  -> Runtime Error 13: Type Mismatch.</FONT></FONT>

    <FONT face=Arial size=2>It DOES blow up... [|-)]</FONT>

  • (cs) in reply to RobIII

    Given once again that this is a scripting engine,  His calling function could easily return that to the User.  (Which would be the correct thing to do for a mis-typed script)

  • (cs) in reply to Konijn

    >You guys are morons, this is a part of a scripting engine.

    I assume the original post was a joke.

    If not -- I'd expect a scripting engine to take a string and work with that.

  • (cs) in reply to podperson

    It does take a string.  this is a SUBROUTINE.  Ever hear of them?  Do you expect a scripting engine to work all in one SUB?

  • El Bit Justiciero (unregistered) in reply to GunslingerRR

    Sometimes, there can be legitimate uses for things like this, although not exactly. The whole argument management is stupid, but the basic concept has its applications in some environments.

    I have found myself doing this with Microsoft FoxPro 2.6 (for Windows 3.x), where you could not write that much code in button and control definitions and were forced to call separate funcions instead.

    Now, having a separate function for each button in your application is sick. Imagine, for example, all the navigation buttons in your customer form, calling functions cliFirst(), cliPrev(), cliNext(), cliLast(), cliSearch(), cliAdd(), cliDel(), cliEdit(), cliDetails, and so on. But that's only the beginning, because you have also a form for vendors, and then new functions vndFirst(), vndPrev(), vndNext(), vndLast(), vndSearch(), vndAdd(), vndDel(), vndEdit() and vndDetails() are born.

    Since all client navigation and editing functions share some code and set the same status flags on and off, and the same occurs with vendor functions, I resorted to define one big function for each form, namely cli() and vnd(), which you would call this way: cli("EDIT"), vnd("DELETE"), and so on.

    Every WTF in this world has its uses...

  • (cs) in reply to Sten
    Anonymous:
    The linux kernel code for socketcall() looks remarkably like this.  Just why they didn't implement one system call per socket function is beyond me.

    Fun,

    Sten


    In fairness, they did.  The manpage for socketcall says "User programs should call the appropriate functions by their usual names.  Only standard library implementors and kernel hackers need to know about socketcall." and it is implemented as a switch which calls the appropriate function just as if the user had called it directly.  The question, then, is why does that function exist, and the best (i.e. only) answer I can find in the Linux Kernel Mailing List archives is "historical reasons", in 1999.  Ahh, ain't cruft great [:)]

  • Tim Hall (unregistered) in reply to Konijn

    "Maybe us morons and lamers have heard of Eval before ?"

    Would you be the same morons that think VB has an Eval function ?

  • (cs) in reply to boohiss

    Anonymous:
    If the string is numeric, the converted (& truncated if decimal) int is returned. If it's not, an exception is thrown (whoops...VB...) it blows up.
    Incorrect. If the string is not numeric, CInt returns a 0.

    It WILL throw an error.  If you try to convert a String into a integer with CInt() and there is text in it, it will throw a System.IvalidCastException error stating that Cast from string "blah" to type Integer is not valid.

    dim myStr as String = "Blah"

    dim i as Int32

    i = CInt(myStr)   'will throw a System.InvalidCastException

  • (cs) in reply to cm5400
    cm5400:

    Anonymous:
    If the string is numeric, the converted (& truncated if decimal) int is returned. If it's not, an exception is thrown (whoops...VB...) it blows up.
    Incorrect. If the string is not numeric, CInt returns a 0.

    It WILL throw an error.  If you try to convert a String into a integer with CInt() and there is text in it, it will throw a System.InvalidCastException error stating that Cast from string "blah" to type Integer is not valid.

    dim myStr as String = "Blah"

    dim i as Int32

    i = CInt(myStr)   'will throw a System.InvalidCastException

    (Grumbles... Fixes Error Should be a System.InvalidCastException.)  Alex, can we edit our posts Pleeeeease??????

  • (cs) in reply to Tim Hall

    Anonymous:

    Would you be the same morons that think VB has an Eval function ?

    Try looking up the Microsoft Scripting Control before calling people morons.


     

  • (cs) in reply to A Wizard A True Star
    A Wizard A True Star:

    Anonymous:

    Would you be the same morons that think VB has an Eval function ?

    Try looking up the Microsoft Scripting Control before calling people morons.

     

    HAHAHA!   You truly are moronic

    Why would one use Microsoft Scripting control when writing a scripting engine?

    That like saying you are gonna build a boat, but start out with the USS Iwo Jima.

  • Tim Hall (unregistered) in reply to Otac0n

    "HAHAHA!   You truly are moronic

    Why would one use Microsoft Scripting control when writing a scripting engine?

    That like saying you are gonna build a boat, but start out with the USS Iwo Jima."


    Couldnt have said it better myself.

    And there are perfectly valid reasons for making your own script engine over using the script control.

  • (cs) in reply to Otac0n
    Otac0n:
    A Wizard A True Star:

    Anonymous:

    Would you be the same morons that think VB has an Eval function ?

    Try looking up the Microsoft Scripting Control before calling people morons.

     

    HAHAHA!   You truly are moronic

    Why would one use Microsoft Scripting control when writing a scripting engine?

    That like saying you are gonna build a boat, but start out with the USS Iwo Jima.

    I was replying to the statement "people who think there is an Eval function in VB are morons". I never said Eval was useful in the context of this particular WTF. But, if you feel like twisting my words around to prove you're the only non-moron here, have a ball.

     

  • (cs) in reply to A Wizard A True Star

    There is no way to Eval VB Code.

  • Bubba (unregistered) in reply to boohiss

    WTF language are you using where CInt returns a 0 for non-numeric strings?

  • (cs) in reply to Bubba

    he was probably thinking of the "Val" function

Leave a comment on “Scaling Expandable Extensibility”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article