Error system not working ?

[rhlawek]

I grabbed a copy of adir.prg out of the samples folder to test with. I get an error log when linking errsysw_.prg, showing this failing on line 556, which is a call to FWBitMap()

Called from FWBITMAP(0)
Called from ERRORDIALOG(556) in c:\fwh\source\function\errsysw_.prg
Called from (b)ERRORSYS(306) in c:\fwh\source\function\errsysw_.prg
Called from MAIN(12) in adir.prg

I also get an error for a redundant function declaration.

FiveHC.lib(MEM.obj) : error LNK2005: _HB_FUN_NEXTMEM already defined in errsysw_.obj

Robb

[nageswaragunupudi]

The default Errorsys is working.

Errsysw_ is not. This is the nicer one because it allows a customer to take an action and email the error log to support immediately ( a huge service ).

Tim

If this is the facility required, this can be done by setting bUserAction codeblock.

We can set this action by calling the function

Code: Select all  Expand view

SetPostErrorAction( bAction ) // --> bPrevAction

When this codeblock is set, this is evaluated with parameters cErrorLogFile and oErrorObject, after the error dialog is closed.

Our function can be

Code: Select all  Expand view

function MyPostErrorAction( cLogFile, oError )
  < do whatever I want .. email .. or store in a separate place, etc>
return nil
 

This allows greater flexibility to the programmer.
We can set this by calling SetPostErrorAction( bAction ) somewhere in the beginning of the project.
 

[Roger Seiler]

I've had a similar problem to Tim's with 8/2013 versions of both FWH and xHb.com. I'm using Errsysw.prg slightly modified to display some instructions to the user, etc. In my case on Win 7, if the error is that a file can't be opened, then I get a Windows error message and no activation of errsysw. But it seems other errors will activate errsysw normally. I haven't yet tried inserting func nExtMem() ; ret 0 but will do that and test.

Incidentally, quite a while ago I added a few lines of code to my version of errsysw in order to retain prior error log info up to a limit of 55K. This is very useful when looking for a pattern in related errors. I highly recommend this modification:

Code: Select all  Expand view

   // If an Error.log already exists, add it to bottom of cErrorLog.
   // I added this to retain prior error messages up to limit of 55k
   // so that useful prior error info won't be overwritten.
   IF FILE("Error.log")
      cText := MEMOREAD("Error.log")
      // Put in a couple lines of asterisks to separate new error from old...
      cText := CRLF+CRLF+REPLICATE("*",50)+ ;
               CRLF+REPLICATE("*",50)+CRLF+CRLF+cText
      cErrorLog += cText
      IF LEN(cErrorLog) > 55000
         cErrorLog := SUBSTR(cErrorLog,1,55000)
      ENDIF
   ENDIF

   // Generates a file with an Error Log  ( this is already in Errsysw.prg ...)

   BEGIN SEQUENCE
      oOldError = ErrorBlock( { || DoBreak() } )
      MemoWrit( "Error.log", cErrorLog )
   END SEQUENCE
   ErrorBlock( oOldError )
 

- Roger

[Roger Seiler]

Just to clarify the error where Windows intervened to shut down the app instead of letting Errsysw do its work, in my case the error was caused by my misspelling a file name so the file couldn't be found (old DOS error 2 I think). It wasn't a syntax error of some sort - those still seem to generate standard Errsysw errors here. But I'll do some more testing here and report back.