Advice on error handling

[AlastairP]

I am debugging my first app on the server at work.
When I get a minor error, TALK activates and I see this on the active form. If I close that from, the talk is then visible on the next form.
Is there a way to stop this and reset the talk option?

 

[Mike Lewis]

Are you saying you want TALK to be active, or that you don't want it?

I assume you know that SET TALK ON or OFF controls the setting. And, also, that is it is scoped to the data session. In other words, if each form has its own private data session, you need to SET TALK separately in each form (usually in the Load event).

In addition, you can set the form's AllowOutput property to specify whether TALK output goes to the form itself or the main window.

If this doesn't answer your question, could you clarify exactly what you want to know.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

SET TALK ON does not report errors, so I think your mixing several things togther here, AlaistairP.

VFP is verbose on command results, eg how many records have been processed. If you turn off the status bar and don't turn off TALK via SET TALK OFF you get messages written on the active form.

Mike has given you a solution to that messages, but it's not error messages.

For handling errors you can use TRY..CATCH..ENDTRY, the Error() method of objects and ON ERROR. If code in there is using ? to print messages, then don't do that, but that would not have anything to do with the TALK setting.

Bye, Olaf.

 

[AlastairP]

Hi Olaf, Mike,
Sorry, I was not being specific.
I have set "SET TALK OFF" in the load event of all my forms, and
want it to stay that way.
For instance, if an error occurs on a form, TALK becomes visible, like you said I see the commands and records processed etc.


I have this on the first line of my main.prg:
ON ERROR DO ErrorHandler WITH ERROR( ), MESSAGE( ), MESSAGE(1), PROGRAM( ), LINENO(1)

Would I use TRY..CATCH..ENDTRY in that location for best handling of errors?
I have not used TRY..CATCH..ENDTRY before.

Regards
Alastair

 

[Mike Lewis]

Alastair,

I'm still not clear exactly what you are seeing.

When you say "TALK becomes visible", do you mean the TALK output from the error-handler itself? Can you give an example of some particular output and the command that produces it?

Regarding TRY / CATCH /ENDTRY, that is not going to make any difference to this particular problem. Rather, it is an alternative to the ON ERROR command - in certain specific circumstances. Given that you have an ON ERROR anyway, you should leave that alone for now.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[AlastairP]

Hi Mike,

If any error occurs, I get the error handler message then the VFP commands and code execution becomes visibly overlaid on the left side of the form.
Like you can see in the VFP IDE during design time.

Alastair

 

[GriffMG]

I have experienced this myself.

Usually when running a routine that sets output to a text file (or .csv or whatever) and 'an error' occurs which isn't trapped properly - usually because I've used one that just carries on by default - and the text that should have ended up in the text file goes to the screen instead.

I would make sure that there is an error handler, with no default option that just lets the code continue from the next line... then see if it gets triggered before your code erupts over your form

If in doubt, try this one:

PROCEDURE USUAL
	PARAMETERS MLINENO,MPROG
	PRIVATE MPROG,MLINENO,MSGLINE
	MSGLINE = "Sorry! An Error Has Occurred: "+CHR(13)+CHR(10)
	MSGLINE = MSGLINE + "Error No.: "+ALLTRIM(STR(ERROR()))+CHR(13)+CHR(10)
	MSGLINE = MSGLINE + "Nature: "+MESSAGE()+CHR(13)+CHR(10)
	MSGLINE = MSGLINE + "Details:"+MESSAGE(1)+CHR(13)+CHR(10)
	IF PARAMETERS() >1
		MSGLINE = MSGLINE + "Procedure:"+MPROG+CHR(13)+CHR(10)
	ENDIF
	IF PARAMETERS() >0
		MSGLINE = MSGLINE + "Line No.:"+ALLTRIM(STR(MLINENO))+CHR(13)+CHR(10)
	ENDIF
	MSGLINE = MSGLINE + CHR(13)+CHR(10)

	MESSAGEBOX(MSGLINE,48,"Error")
	ON SHUTDOWN
	CANCEL
	RETURN

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[DSummZZZ]

It sounds like you are saying the TRACE window becomes visible, not TALK. This is the normal behavior for VFP. The error pops up and the trace window opens so you can see where the error occurred.

Your ON ERROR routine may be getting overridden somewhere else in the code though, or that window wouldn't pop up.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[Mike Lewis]

Alastair,

I'm sorry, but you're going to have to explain the problem more clearly.

You said "the VFP commands and code execution becomes visibly overlaid on the left side of the form. Like you can see in the VFP IDE during design time."

I really can't make out what you mean by "commands and code execution" becoming visible. And I can't think of any case where you see anything like this "on the left side of the form in the VFP IDE during design time".

Please try to describe exactly what you are seeing.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

Are you seeing the debugger?

Check out the Options. Main Menu -> Tools -> Options, there in the Debug tab you can choose, if the debugger runs in it's won window "Debug Frame" or in the foxpro screen "Foxpro Frame". In the latter case you may only see the trace window, but it's title does not say "Talk".

Anther reason you see TALK messages within error handling can simply be, because you did not SET TALK OFF in the first, public, general datasession where main runs and sets your error handler. Even if you have SET TALK OFF in all your forms load event, if forms are started in a private data session you never set this for the initial data session.

Bye, Olaf.

 

[AlastairP]

Hello,
I don't think I am seeing a trace window.. or the debug.
I think I will do a screen capture next time it happens and upload the picture for you to see.

Here is part of my main.prg :

********************
PROCEDURE SetCommands
********************
LOCAL lcPath
SYS(2700,1)
SET BELL ON && Turns the computer bell on
SET CENTURY ON && Specifies a four-digit year in a format that includes 10 characters
SET CONSOLE OFF && Disables output to the main Visual FoxPro window or to the active user-defined window from within programs
SET DELETED ON && Specifies that commands that operate on records, including records in related tables, using a scope ignore records that are marked for deletion
SET ESCAPE OFF && Pressing the ESC key interrupts program and command execution
SET EXCLUSIVE OFF && Specifies that tables are opened for shared use on a network
SET HOURS TO 12 && Sets the system clock to a 12-hour time format
SET MULTILOCKS ON && Required for row or table buffering and allows multiple records to be locked using LOCK( ) or RLOCK( )
SET REFRESH TO 5,3 && Frequency (in seconds) to update a browse window or memo editing window, or to refresh local memory buffers - 1st parameter is for local data, 2nd parameter is for network data
SET REPORTBEHAVIOR 90 && Using the new reporting engine features
_REPORTOUTPUT = "ReportOutput.app" && Designate application to use for report output
_REPORTPREVIEW = "ReportPreview.app" && Designate application to use for report previewing
SET REPROCESS TO 5 SECONDS && How long will Visual FoxPro attempt to lock a file or record after an unsuccessful locking attempt
SET SECONDS OFF && Specifies that seconds are not displayed in the time portion of a DateTime value
SET STATUS BAR off && Displays the graphical status bar at the bottom of the _screen
SET SYSMENU OFF && Turn off the default system menu that Visual FoxPro uses
SET TALK OFF && Prevents talk from being sent to the main Visual FoxPro window, the system message window, the graphical status bar, or a user-defined window
SET DATE TO DMY

Alastair

 

[TamarGranor]

I think your error handler is probably SETting TALK ON. Did you check that code?

Tamar

 

[AlastairP]

Here is the code for the error handling:

ON ERROR DO ErrorHandler WITH ERROR( ), MESSAGE( ), MESSAGE(1), PROGRAM( ), LINENO(1)



********************
PROCEDURE ErrorHandler
********************
   PARAMETER tnError, tcMessage, tcMessage1, tcProgram, tnLineno
   LOCAL lcErrorMessage
   lcErrorMessage = "Error number: " + TRANSFORM(tnError) + CHR(13) ;
      + "Error message: " + tcMessage + CHR(13) ;
      + "Line of code: " + tcMessage1 + CHR(13);
      + "Program: " + tcProgram + CHR(13);
      + "Line number: " + TRANSFORM(tnLineno)
   MESSAGEBOX(lcErrorMessage, 16, "A Problem Has Been Encountered")
   CLEAR EVENTS
ENDPROC

I just copied this directly from a sample main PRG

Alastair

 

[GriffMG]

Hmm

Comment out 'clear events' and you have mine

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[Olaf Doschke]

Your error handler ends the program, CLEAR EVENTS clears the READ EVENTS and goes back to the code after READ EVENTS which typically ends an application, if you don't have code there restarting the app.

Bye, Olaf.

 

[GriffMG]

True.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[Mike Lewis]

Alastair,

You said that you thought you were seeing the Trace window.

This is a window where you see the source code that is being executed, with a little yellow arrow to the left of the actual line of code being executed.

Can you confirm that is what you are seeing?

If so, that is exactly what you would expect if you click Suspend when an error message appears. VFP displays the trace window to help you debug your code.

If you don't want to see the trace window, you can simply close it. Alternatively, go to Tools / Options /Debug, and set Environment to Debug Frame. In that case, the trace window will still appear, but it will have a separate taskbar button, so you can easily switch back to the main VFP window.

If what you are seeing is not the trace window, then you will still need to explain what you are seeing more carefully. Maybe a screen shot will help.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[AlastairP]

Olaf, you may be on to something here:
When I get an error, the app does not close THE FIRST TIME,
but will close if the error occurs a SECOND TIME.
Between the first error and the second is when I get the problem with the unwanted stuff appearing on the form.


Alastair

 

[Olaf Doschke]

Well, Alastair,

CLEAR EVENTS doesnot immediately end an app, the method executing must first finish. If you add CANCEL in the error handling you cancel further code execution. But that does not eyplain why you see unwanted stuff on your form. Is it really on the form canvas or another window opening in front?

To demonstrate how CLEAR EVENTS does NOT finish directly:

On Error Do errorhandling

o = CreateObject("myForm")
o.Show(2)
Read Events
MessageBox("now I finished")

Procedure errorhandling()
   MessageBox("an error occurred")
   * Cancel
   Clear Events
EndProc

Define Class myform as Form
    Add Object cmdError as Commandbutton
    
    Procedure cmdError.Click()
       MessageBox("I will now error")
       Use dfhjksdjfkhddfsdf && causes file not found error.
       MessageBox("I still continue")
    EndProc
EndDefine

Run this, click on the command button in the form appearing. You will get the message announcing an error, a message from the errorhandler and then the message from the click code after the erroneous line, which you might not expect.

CLEAR EVENTS clears the READ EVENTS, but only after the callstack is empty and code execution has finished. After the errorhandler procedure finishes you continue in the click after the error line.

Now uncomment the CANCEL and then the clear events will immediately work.

If you want to see what's going on, simply add "SET STEP ON" in your errorhandling before CLEAR EVENTS.

Bye, Olaf.

 

[AlastairP]

Olaf, thanks very much for your help.