Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
ON ERROR Macro Substitution
Message
De
04/06/2013 19:50:18
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Versions des environnements
Visual FoxPro:
VFP 9 SP1
OS:
Windows XP SP3
Network:
Windows 2003 Server
Database:
Visual FoxPro
Application:
Desktop
Divers
Thread ID:
01575512
Message ID:
01575663
Vues:
52
>>>Hi Gang!
>>>
>>>question.... I have, in some old code, a routine that may or may not have an ON ERROR error handler activated when starting the code.
>>>
>>>Any way to save what the rest of the ON ERROR part is, to a variable, at that point? Any function that tells what the ON ERROR part is?
>>>
>>>Then, I can change the ON ERROR handler to be what I want it to be and run my new code....
>>>
>>>And if the user changes their mind and exits the routine without running my new part, it can restore back whatever the ON ERROR was to begin with, just like nothing has happened.
>>>
>>>Thanks!
>>
>>One other thing to supplement the info from others -- An Error() trap in an object (if it is within the call stack) will take precedence over ON ERROR (at least as far as VFP6 -- hadn't tested if this is also true in VFP7,8 or 9). For example, if you've got an Error event defined in a form, you'll discover that that the form's Error() will trigger instead of the ON ERROR that is defined within the PRG that is called by a form's method. I first got bitten by this when adapting some old FPW code to VFP and used some ActiveX controls as part of the update (namely the Common Dialog control -- as the built-in GETFILE()/PUTFILE() in VFP6 had the limitation of not being able to navigate with UNC paths, and when using the Common Dialog control, you have to have an Error trap to handle some conditions -- otherwise you get a runtime error).
>
>Thanks a bunch!

You're quite welcome. By the way, here is some code that demonstrates what I mentioned about error traps.
#DEFINE _NL_   CHR(13)+CHR(10)

* Here we call PSub2 directly
DO PSub2

* Look what happens if we call PSub2 through context which has ERROR() event defined
oTst = CREATEOBJECT("T_ErrTrap")
oTst.DoCmd("DO PSub2")
IF oTst.bOkFlg THEN
    ? "OK"
ELSE
    ? oTst.cErrMsg
ENDIF

RELEASE oTst

RETURN .T.

PROCEDURE PSub1
    LOCAL cErrTrap, nErrNum

    cErrTrap = ON("ERROR")
    ON ERROR nErrNum = ERROR()
    nErrNum = 0
    = "A"+1
    ON ERROR &cErrTrap.
    ? "nErrNum = ", nErrNum
ENDPROC

PROCEDURE PSub2
    DO PSub1
ENDPROC

DEFINE CLASS T_ErrTrap AS CUSTOM
    bOKFlg   = .T.           && Indicates if everything ran OK or not
    cErrMsg  = ""            && Error message indicating nature of failure

    PROCEDURE ERROR
        LPARAMETERS nError, cMethod, nLine

        THIS.bOkFlg = .F.
        THIS.cErrMsg = "Error "+TRANSFORM(m.nError) ;
            +":"+MESSAGE()+_NL_ ;
            +"Error on line "+TRANSFORM(m.nLine)+" in "+m.cMethod+_NL_ ;
            +"Command: "+MESSAGE(1)
        RETURN
    ENDPROC

    PROCEDURE DoCmd( cCmd )
        &cCmd.
    ENDPROC
ENDDEFINE  && T_ErrTrap
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform