Results 1 to 5 of 5

Thread: Weird behavior from the input (file read) statement...

  1. #1
    Join Date
    Jul 2006
    Posts
    359

    Arrow Weird behavior from the input (file read) statement...

    I'm trying to understand some very weird behavior I'm seeing in the INPUT # statement. I'm using v3.8.50 of the control software.

    Here's a test program:
    open "test.txt" for input as #1
    input #1, &testVal
    print "&testVal = ", &testVal
    close #1

    For the first run, the contents of "test.txt" is this:
    String value

    When you run it, you'll get:
    &testVal = String value

    However, if you change that file to read:
    "String value"

    The output from the print will be the same. The input code is stripping the quotes. Is this behavior on purpose? To me, this is improper function - the behavior isn't documented. Is this a known bug?

    Next, change the file to read:
    text-text

    Instead of the output being "text-text" (no quotes), the program crashes with:
    "Undefined Variable: TEXT (&testVal; 0]"

    This tells me that for some insane reason, it not only thinks that "text" is a variable, but that it's trying to perform a math operation on it!
    Changing the "-" to any math operator generates the same error.

    Is this a known bug?

    Ok, next up, if you attempt to read beyond the end of the file, You'll get a hard error = "Run-time error '62': Input past end of file". THIS knocks down the whole ShopBot Control program. The only window left is the SHopBot Preview window. This is for sure a bug - it shouldn't bring down the house on a simple error like that.

    Thanks all.
    (also, if someone could answer the question I posted on the ShopBot Control Software v3 board, I'd really appreciate it!)

    g.

  2. #2
    Join Date
    Dec 2000
    Location
    Thorp, WI
    Posts
    2,845

    Default

    From the programming handbook... Variables in programming are often defined in terms of specific 'types' based on what kind of numbers or character they are. For example, integer variables, string variables, floating point variables, etc… However ShopBot variables are a generic variable type that is handled behind the scenes as a string variable or floating point number depending on what is appropriate in the situation (similar to 'variant' data type for those familiar with Visual Basic). This means you will not need to worry about variable typing.

    When mathematical operations are carried out, if a variable can be made into a number it is handled as a single precision floating point (7-8 digits precision). If you use variables for counters and test for the end of the loop with an IF test, then test with an ">" or "<" rather than an "=" because the variable may not be stored as precisely the number you expect (i.e. a number that you expect to be “1” might actually be “1.000001”).

    If you change your text-text to test_test, it works fine.
    Scott




  3. #3
    Join Date
    Jul 2006
    Posts
    359

    Default

    I know that it works fine if I do that. The problem is that an input statement shouldn't be interpreting data read from disk as if they were variables, let alone trying to perform a math operation on them. I need to understand if the behavior is on purpose and I have to hold my nose and replicate this insane behavior, or if it's a bug and I don't.

    I did discover that stripping quotes /can/ be a common behavior in other environments, but I've got more research to do.

    I'm not sure why you quoted the manual to me - it doesn't have anything to do with the issue at hand.

    g.

  4. #4
    Join Date
    Dec 2000
    Location
    Thorp, WI
    Posts
    2,845

    Default

    Just to show that SB doesn't look at variables as strictly string or integer and adding a math operator in the mix causes the &testval value to be 0. Who know the what and why of a more than a decade old visual basic program. Time for something new.
    Scott




  5. #5
    Join Date
    Jul 2006
    Posts
    359

    Default

    Again, the problem isn't the variable type - it's the fact that a command to read data from disk is attempting to do things that are WAY outside the scope of what the command is apparently intended to do.

    g.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •