ON ERROR

[JTHURT]

I added this to my program but the programs ignores it.

ON ERROR DO myopenerror
use homesv in a
ON ERROR

procedure myopenerror
? "Ran this"
endproc

The homesv table does not exist.
The program defaults to the application error handler.
(Got this information from the debugger.)
Why doe it not execute the ON ERROR

 

[danceman]

i am using fox 6.0 sp 5 and it works for me. Attitude is Everything

 

[DSummZZZ]

Where is procedure myopenerror?

Is it in a separate .prg? Did you SET PROCEDURE TO the separate .prg?

I copied you code and put it in a .prg and it ran as expected.(?)
Dave S.

 

[JTHURT]

The procedure is in the same program that I call from the menu.

The on error works when I run the program during development but doesn't when I call it from the menu.

I am also running 6.0 sp 5.

 

[darrellblackhawk]

If the error occurs in a method of an object, and you have even a comment in that objects error method, the error will not bubble-up to your 'on error' statement.

Check your containership hierarchy for error methods that may be stopping your on error from firing.

Darrell 'We all must do the hard bits so when we get bit we know where to bite'

 

[JTHURT]

containership hierarchy?
How do I check it?

 

[danceman]

start with the object where you call the code. this object has a error event. it should contain nothing. then check the error event in the base class of the object. this will continue up the chain to the base class of the object. if no code is in the event then the on error is called. of you can't find it then in the error event of the object, call your routine from the event with the prameters passed in the event. Attitude is Everything

 

[darrellblackhawk]

Sorry for the geek speak.

I mean check that any controls contained in other objects(i.e. pushbuttons inside of forms, textboxes inside of containers, etc.) aren't intercepting the error and leaving it unhandled by not testing for it.

If any are - by way of having an error method with code - you'll have to explicitly call out to your 'on error' code or remove the control's error code which may not be viable.

Doug Henning has an excellent treatise on error handling at:

http://www.pinnaclepublishing.com/FT/FTmag.nsf/0/F3A7479B0D2D65F8852568E9004F2CF1

In it, he discusses the issues I'm referring to above.


Darrell 'We all must do the hard bits so when we get bit we know where to bite'

 

[danceman]

striaght from the help file

When an error occurs in method code, Visual FoxPro checks for error-handling code associated with the Error event of the object. If no code has been written at the object level for the Error event, the Error event code inherited from the parent class, or another class up the class hierarchy, is executed. If no code has been written for the Error event anywhere in the class hierarchy, Visual FoxPro checks for an ON ERROR routine. If no ON ERROR routine exists, Visual FoxPro displays the default Visual FoxPro error message.

the travel is up the inherited class, testbox, form......

The beauty of classes is that you can encapsulate everything a control needs, including error handling, so that you can use the control in a variety of environments. Later, if you discover another error the control might encounter, you can add handling for that error to the class, and all objects based on your class will automatically inherit the new error handling.

Attitude is Everything

 

[darrellblackhawk]

Very well written Danceman.

Darrell 'We all must do the hard bits so when we get bit we know where to bite'

 

[danceman]

thanks Darrell

Attitude is Everything

 

[JTHURT]

Thanks!!
I got diverted.
I am checking the method now.
Thanks again!!!

 

[chpicker]

JTHURT,

I'm venturing a guess based on a comment you made above:

The on error works when I run the program during development but doesn't when I call it from the menu.

Is the code you posted above part of a menu procedure? If so, this is your problem. The actual menu procedure is executed once and then unloaded from memory. You will either need to put your error handler in another PRG file and use SET PROCEDURE or include the error handler in your main PRG.

If this isn't the case, then feel free to ignore what I just said. )

Ian

 

[xBaseDude]

To expand on what Ian said....

Have a main prg that gets the ball rolling....

START.PRG

SET DELE OFF
PUSH KEY CLEAR
SET YER ENVIRONMENT SETTINGS etc...etc...
ON ERROR do myerrtrap && (I use a prg called myerrtrap.prg)
DO mymenu

HTH - Wayne