Inconsistant Run-Time Errors 1

[anyhandle]

Hi,
A simple bug showed during run-time, but only on the third successive run of the application with no changes. It's upon start-up; therefore it's not dependent upon any user interaction. I walked thru the code and it should have given an error message every time, not just on the third try. The error was simple:

if misc.ico=.f. &&where misc.ico is a character defined field and I'm assigning a logical value

Apparently, FoxPro (at times) blows by errors rather than give error messages during run-time. If no one else is experiencing this, it may very well be a problem with converted applications (as this one is).

This same exact situation occurred (assigning the wrong data type) elswhere in the app where I wrote that line over a year ago and have used it successfully over 400 times! It wasn't until I installed a fresh version of Visual FoxPro
and the service pack #5 that it suddenly gave me a data mismatch error.

Any thoughts? This is embarassing when I test the app, think it's error free, then am called regarding a bug which never displayed. (and I did test this on a second machine). As a matter of fact, the same exact situation happend
to the client calling with the bug. The computer atmosphere doesn't seem to make a difference here.

Thanks

 

[GemWarner]

Without seeing the code it's like feeling around in the dark for a light switch... but my best guess would be to check the variable type before running your "if" statement that way you'll know what the variable type is before you test for it's contents.

I can only guess that you need to have this variable switching between a character and a logical type as opposed to creating two variables each with the relevant type you wish to assign.

Hope this helps

Gem aka "the new KID"

 

[anyhandle]

Thanks for your response. Believe it or not "if misc.ico=.f." (&&where misc.ico is a character defined field and I'm assigning a logical value) is the code I'm discussing. Because (at times) I put in long days, I was obviously half sleeping when I wrote this. I DO depend on the VFP's error handler to catch these things because if it doesn't, that means testing EVERY variable and table field EVERY time I make a maintenance change. That's not feasible. It isn't that I made a mistake that worries me. It's that the VFP error handler didn't catch it that worries me.

You're right I could put in a boat load of 'CYA' code, but ultimately I'd feel more comfortable if my error handler was working properly. I also wanted to know if anyone else is having this problem or if it's isolated to me.

Thanks again.

 

[Diederik]

For what it's worth:

IF misc.ico = .F.

will generate an error if misc.ico is a char variable. However, if misc.ico contains a NULL value, no error will occur.

VFP's error handler does catch this error (error 107), so this could point to a problem in your error handler.

You where obviously already asleep when writing this code, as checking on a logical condition using

IF uVar = .F.

is IMHO just a difficult way of doing

IF NOT uVar

;-) Diederik Vermeeren
verm1864@exact.nl

 

[anyhandle]

I think you got part of it!
Your statement "misc.ico contains a NULL" is probably why I didn't initially get an error. It'll only give an error AFTER a value is inserted.

However, during the second time I was asleep, I was asigning a numerical value to a character field. Since I ran past this code 400 times during 400 runs of the app (200 actually because it only views this code every other run), the error handler should have given me an error regardless if the field is filled or not. It does; however, give me an error when I try this in the command window.

Well, I'll be more careful of my null's, but I still think something is wrong with my error handler.

Thanks for your input.