Why am I getting a "row or column is off the screen" error here?

Question

Hi guys. I'm actually not a developer of VFP. I'm a pinball tech. But I do have a VFP problem, and some knowledge of coding.

Story: Our company's work order system was created in Fox Pro, probably around about 1987. Since no one here knows a thing about coding, it has simply been carried along from one computer to the next in any way possible for the last 24 years. We recently upgraded to Windows 7, and now the poor old program is throwing an error and will not let us print.

When we try to print, we get an error message "Row or Column is off the screen". After this, the program shows a red screen and refuses to work anymore. If we hit ignore, sometimes a number or two will appear on the screen.

The relevant part of the code appears to be this simple bit:

PROCEDURE PRNT_WO
*****************
SET COLOR TO RGB(0,0,0,0,255,0)
SAY 'PRINTING OCCURRING, PLEASE WAIT!'
SET COLOR TO RGB(255,255,255,0,0,255)
SET FILTER TO WO.ORDER_NO=MORDER
REPORT FORM WORKORDR TO PRINT NOCONSOLE PDSETUP
GO TOP
RETURN

But when I search for the error, it says it has to do with @ commands. I see no @ command. It's possible it's encountering a different error, and having an error within the error report.

PROCEDURE ERRPROC
RELEASE WINDOW
IF ERROR()=108.AND.ACTION='A'
    @ 22,0
    SET COLOR TO W+/R
    @ 22,0 SAY "RECORD BEING APPENDED AT ANOTHER STATION, TRY AGAIN"
    WAIT
    SET COLOR TO GR+/B
    @ 22,0
    RETRY
    RETURN
    ENDIF
IF ERROR()=109.AND.ACTION='D'
    @ 22,0
    SET COLOR TO W+/R
    @ 22,0 SAY "RECORD IN USE AT ANOTHER STATION, TRY AGAIN"
    WAIT
    SET COLOR TO GR+/B
    @ 22,0
    RETRY
    RETURN
    ENDIF
SET COLOR TO W+/R
@ 21,0
@ 21,0 SAY ERROR()
@ 22,0 <---
@ 22,0 SAY "RECORD SYSTEM ERROR - IN PROGRAM: "+SYS(16)
SET COLOR TO GR+/B
WAIT
RETURN

Which does have @'s in it. I put in the little"<---", it's not actually in the code. This is where the debugger arrow points when I run it. But, I have no idea why.

It didn't do this when we were on XP, but I assume the version of VFP was upgraded when we upgraded the computers. So, any ideas? Help?

Answer 1

Your code looks like an early version of FoxPro for Windows because it has @ symbols in it (referred to verbally as "at say").

First, if you have the FoxPro development discs, or program, that would allow the work order system to be debugged (tracing down the error), by you or a programmer.  Tracing the error is necessary to discover the cause. 

If you could tell us what state you're in, perhaps a nearby programmer could take a look.

I could offer to connect online with you (I'm in Illinois), and guide you with Go to Meeting, or similar program, if needed, for a fee.

Tom

Answer 2

I agree with your suggestion that the problem is in the error handler because with an error handler in place, you should get FoxPro error messages from the other code.

My best guess is that the new computer has a wide-screen monitor (so it's short and squat) and that it doesn't have 22 rows available. You could try bumping all the row numbers in the error handler up (well, down numerically) until you find a value that works.

If you're comfortable working in the VFP Command Window (which it looks like you are), try entering ?SRows() and see what value it displays. That's the number of screen rows available with the current font.

Tamar

Answer 3

Your error routine is the source of the error. If you have a source code of the program and can invite a VFP programmer to take a look, it may be better.

Basically, this program needs to be re-written in the new way, but the re-write into a new technology may be an expensive task. It is probably possible to patch it a bit (at least change that error routine to something better).

For now, I suggest you to do the following. Find ON ERROR command in your program and comment it out (put a * in front of it). Let the program fail instead of using this bad error routine. Recompile it and try to use. There is another error in that code, but it's obscured by that error handler.

---

For every expert, there is an equal and opposite expert. - Becker's Law


My blog

Answer 4

CadillacMusic:

I just noticed a possible cause.  In the PRNT_WO procedure, just before the REPORT FORM, the line

                               SET FILTER TO WO.ORDER_NO=MORDER

contains a variable MORDER.  If that variable is not "in scope", it will trigger an error.

"In scope" basically means can the program "see" the variable inside this procedure.

There are a number of ways to make a variable "in scope", but at least you can check on this possibility.

Tom

Answer 5

You guys are awesome, thanks!

As to hiring someone... we're in Cleveland, but clearly if the boss hasn't thought it enough of a problem in the past to get the code updated, there's no reason he's gonna change now.

I tried ?Srows() and it gave me back 22.000 . So...it should fit, no?

Also, it's not a widescreen monitor, and the program runs in a little dos-box type thing anyway.

How do I check if a variable is in scope?

I will try editing out the error thing, but I'm a little chicken, because I'm not great with vpf. Like, I tried editing out the two say lines in prnt_wo, just to see what would happen. Next time I typed prnt_wo into the command line, it kept saying there was no such program. I even tried DO prnt_wo, and it couldn't find it, even though I could see PROCEDURE PRNT_WO on the screen in front of me.

Answer 6

In the main procedure of the application there should be a line

ON ERROR DO ErrProc 

I suggest to comment this line (add * in front of it). It will mean that the program will no longer have an error handler and if it encounters an error, it will show the error right away. I feel it's better than current way anyway.

I also agree that the problem is most likely with the filter command.

---

For every expert, there is an equal and opposite expert. - Becker's Law


My blog

Answer 7

Sadly, commenting out the ON ERROR does nothing. In fact, if I run the debugger, I swear it still calls ERRPROC.

If it's the filter....how do I fix it? Commenting out the filter line still leads to the same error message.

Answer 8

That's weird, but try searching the whole project for ON ERROR. You can also change this routine to 

=MESSAGEBOX('Error encountered : '  + transform(Error()) + ' ' + message(), 16, 'Program Error')

and comment out the rest of the code. If the commenting FILTER line still leads to an error, then the error must be something else.

---

For every expert, there is an equal and opposite expert. - Becker's Law


My blog

Answer 9

Ah, that's helped it. Ok, so the ERRPROC was causing the row or column error. But there's still an error in prnt_wo that's making it call ERRPROC. All ERRPROC tells me, though, is that it is called from prnt_wo which is called from wmenu...etc, etc. So something's wrong with prnt_wo, either the filter or the report form. Investigating futher....

Again, thank you everyone for all your help so far.

Answer 10

Ah, there is no WO.ORDER_NO, because there is no WO! The alias got messed up. WOOHOO. Thank you so much everyone.

Answer 11

Glad you figured this out.

---

For every expert, there is an equal and opposite expert. - Becker's Law


My blog