String to integer

[Moneo]

Well, if the string is from a file you wrote with a guaranteed legal value, then k%=val(S$) is good. But if it is a value supplied by the user, you need to check for validity unless you are the only user or you know only skilled QBasic programmers are supplying the input. Otherwise your program will bomb or give strange results.

Mac

Very nice interger validation function, Mac.

Sad to say many programmers ignore, or don't bother, doing input validation. I once figured out that input validation for a program having heavy input, like a master file update, will take about 75% of the code of this kind of program.

The old saying of "garbage in, garbage out" really applies. I'm glad that programmers like you are aware of this.

I do have a comment about your statement about skilled programmers supplying the input. Experience has shown that skilled programmers or users skilled in the application are not the best providers of input. The best are data entry clerks, although these are now disappearing. That was their one and only job, and they knew the data and related codes better than anyone.
*****

[Mac]

Hi, Moneo,

Thanks for the reply.

By "skilled programmers" I was thinking of the case that you ask for a number and the user enters something illegal and something like this happens:

Enter number of widgets 0-22222

And the user enters 44444 by accident

and k%=val("44444") bombs out and now the user is stuck in QBasic with the Overflow message. A standard non-programmer user is lost and should never get to that spot. A skilled QBasic programmer would be able to recover, for example
- temporarily comment out the VAL statement
- manually enter a correct k%
- step down an instruction using F8
- uncomment the VAL statement
- continue the program

Or at a minimum, the skilled programmer would know to simply hit shift-F5 to start over. Unskilled users should never get a STOP. That, in my opinion (and it looks like yours too) is simply a bug in the program. That's why, for example, I always use LINE INPUT and never INPUT (again unless I am the only user, etc.)

Cheers!

Mac

[Moneo]

Mac,

When QBasic came out, I was already a fervent user of Quickbasic 4.5, so I never converted to QBasic.

I get the impression from your post, that you might deliver a program to a user in source form, and that he would run it under QB in an interpreted mode. Hence the possible in-line error messages and STOPs.

I always deliver executables to any user, with separate source code depending on the agreement. If I were using QBasic, I would develop and test under QB, and then compile and deliver an executable in the same manner.

Running from an executable does not eliminate error message, of course, but when it happens the program terminates and does not leave the poor user in the middle of the code.

As you well pointed out before, many instances of runtime error messages can be avoided by proper input validation routines within the program, and other error checking like divide by zero.

BTW, yes, I always use LINE INPUT.
*****

[Mac]

Ah, so! Yes, that way, at least, one doesn't get trapped in the IDE.

I started with QBasic 1.0. It was a world-wide military application that, half-way though, we were directed to change from Unix to WindowsNT. We really were accustomed to the Unix SHELL scripts and DOS was a very poor substitute. But WindowsNT comes with QBasic 1.0, so we quickly found that by including "QBasic / run xxx" in our BAT files, we really had the equivalent of SHELL.

We never compiled. A compiled program had to go through extra steps during testing to ensure the Source was correct. Turning in BAT and BAS files was relatively hassle-free.

Personally, I never accept an EXE file from any source except known businesses I can sue if it contains damaging viruses. So my stardard is to use "Start QBasic /run xxx" and "notepad xxx.bas". I sit at the DOS prompt and swap between those two commands using up/down arrow. It's very rare I use the IDE Editor.

Well, to each his own style.

Mac

[Moneo]

Mac,

Since I never use QBasic, it would have never occurred to me to do "QBasic / run xxx" from a batchfile. Yeah, just like we used to do "Basica xxx".

The problem you mention about receiving an EXE file containing damaging viruses, can be said about any program or utility which you buy or obtain. What I mean is that the problem is not unique to compiled Basic programs. It is a valid problem, nevertheless. What I would do in this case is receive the .BAS and then compile it myself.

The problem with keeping .BAS files to use for execution, is the same problem as batchfiles; that is, they're too handy to be changed by a knowledgeable user. The source is not archived in the Source Code Environment with strict Program Change Control procedures, it's right there in the Production Environment where it can be changed more easily.

In addition, EXE files run faster than code interpreted by Qbasic.

But, like you said: to each his own style.

*****

[Pyrokid]

ok this topic has gone on WAY TO LONG. All i wanted to know is how to do that. There was too many replies after the first one. so stop replying to this topic

[Z!re]

You could also directly read the memory adress at the var offse...

Oh.. no more replies :lol:

[Mac]

If you were satified with the original simple answers and didn't want to learn any advanced techniques about editing user input, etc., then the simple solution is to unsubscribe from the thread. Presto! You are never bothered ever again!

Meanwhile, it seems like your thread is like many other threads on any forum: sometimes they take on a life of their own (get "hijacked"). Tough. I hate when that happens.

[Pyrokid]

If you were satified with the original simple answers and didn't want to learn any advanced techniques about editing user input, etc.

lol the thing is i knew the other techniques

[Z!re]

Tough. I hate when that happens.

We know Mac.
And that is why you know noone, and noone cares about you.

We dont know you, you're a nobody, as you never take part in the "qmunity" posts/topics.
The topics you shun.
The non-coding topics.
Where we get to know each other and form bands..

Have fun.