locked
MsgBox Error$ replacement RRS feed

  • Question

  • Howdy,

    I understand that "MsgBox Error$" is an old syntax from Access2.  In cleaning up code I've found 90 instances scattered around.

    If I want to replace them with Err.Description at the least or even better something that will return the module and procedure.  Along the lines of 

    MsgBox "Error " & Err.Number & " (" & Err.Description & ") in procedure " XXXXXXX & " of Module " YYYYYYYY

    where XXXXX is the procedure name and YYYYY is the module.

    Right now, I've been putting in the error handlers using MZ-Tools or manualy but if I want to do a find and replace for my Error$ I'm at a loss.

    Ideas?

    /Joe


    Sunday, February 5, 2012 3:38 PM

Answers

  • If you merely want to replace

    MsgBox Error$
    

    with

    MsgBox Err.Description, vbCritical
    

    or similar, you can do that in one fell swoop in the Edit | Replace dialog - set the Search scope to Current Project and click Replace All.

    If you want to add the name of the procedure and module, you'd have to use the Microsoft Visual Basic for Applications Extensibility 5.3 library. Personally, I don't think it's worth the trouble - during development, I can keep track of where errors occur myself, and I don't think it's useful for end users to see the procedure and module names.


    Regards, Hans Vogelaar
    • Marked as answer by Bruce Song Thursday, February 23, 2012 9:20 AM
    Sunday, February 5, 2012 4:18 PM
  • Its a nice idea but you may need to think it through further.  Error handling is a bit of an art and there are few hard and fast rules.

    Your colleague probably left Error$ there for a reason (like he knew the module name by asking the user which form or report was in use when the error was encountered,so why would he want to spend hours putting in the procedure name????)

    Probably the more important thing is what the code should do after the error message has been displayed - or whether the user should be given a more user friendly explanation.

    For example:

    • Once the error has occured, you could terminate the procedure by exitting out of it .... if the code has left database or recordset objects open, you may be better off to close them.  Otherwise the user may find he cannot close the application, it runs out of memory etc, etc
    • You could RESUME NEXT meaning the code goes back to the point where the erro occurred.  Now this could generate even more error messages because of the initial error and look pretty bad .... but it would serve to ensure any instantiated objects are likely to be closed
    • RESUME at some specific label in the code ....
    • Or may be replce some error messages like:
    • If err.number = 3000 then
    • Msgbox "You must enter a valid value !!!", vbOKonly
    • endif
    • Resume  Next

    It is probable the application may need some cleaning up to handle errors in a more user friendly manner - and it may be you need to do more than simply add a procedure name.  You could create a procedure to record errors and login data to a table then decide which messages to analyse further with a view to cleaning up the application.  

     

     


    PG A bit of experimentation by trial and error often helps.
    • Marked as answer by Bruce Song Thursday, February 23, 2012 9:20 AM
    Sunday, February 5, 2012 5:28 PM
  • Further to what Hans V has recommended (which I agree with), I would suggest taking a closer look at "Debug.Print", "Debug.Assert" and the Immediate (debugging) window in the VBA Code Editor, which you can show by holding CTRL+G.
    Matthew Slyman M.A. (Camb.)
    • Marked as answer by Bruce Song Thursday, February 23, 2012 9:20 AM
    Monday, February 6, 2012 10:25 AM

All replies

  • If you merely want to replace

    MsgBox Error$
    

    with

    MsgBox Err.Description, vbCritical
    

    or similar, you can do that in one fell swoop in the Edit | Replace dialog - set the Search scope to Current Project and click Replace All.

    If you want to add the name of the procedure and module, you'd have to use the Microsoft Visual Basic for Applications Extensibility 5.3 library. Personally, I don't think it's worth the trouble - during development, I can keep track of where errors occur myself, and I don't think it's useful for end users to see the procedure and module names.


    Regards, Hans Vogelaar
    • Marked as answer by Bruce Song Thursday, February 23, 2012 9:20 AM
    Sunday, February 5, 2012 4:18 PM
  • Its a nice idea but you may need to think it through further.  Error handling is a bit of an art and there are few hard and fast rules.

    Your colleague probably left Error$ there for a reason (like he knew the module name by asking the user which form or report was in use when the error was encountered,so why would he want to spend hours putting in the procedure name????)

    Probably the more important thing is what the code should do after the error message has been displayed - or whether the user should be given a more user friendly explanation.

    For example:

    • Once the error has occured, you could terminate the procedure by exitting out of it .... if the code has left database or recordset objects open, you may be better off to close them.  Otherwise the user may find he cannot close the application, it runs out of memory etc, etc
    • You could RESUME NEXT meaning the code goes back to the point where the erro occurred.  Now this could generate even more error messages because of the initial error and look pretty bad .... but it would serve to ensure any instantiated objects are likely to be closed
    • RESUME at some specific label in the code ....
    • Or may be replce some error messages like:
    • If err.number = 3000 then
    • Msgbox "You must enter a valid value !!!", vbOKonly
    • endif
    • Resume  Next

    It is probable the application may need some cleaning up to handle errors in a more user friendly manner - and it may be you need to do more than simply add a procedure name.  You could create a procedure to record errors and login data to a table then decide which messages to analyse further with a view to cleaning up the application.  

     

     


    PG A bit of experimentation by trial and error often helps.
    • Marked as answer by Bruce Song Thursday, February 23, 2012 9:20 AM
    Sunday, February 5, 2012 5:28 PM
  • Further to what Hans V has recommended (which I agree with), I would suggest taking a closer look at "Debug.Print", "Debug.Assert" and the Immediate (debugging) window in the VBA Code Editor, which you can show by holding CTRL+G.
    Matthew Slyman M.A. (Camb.)
    • Marked as answer by Bruce Song Thursday, February 23, 2012 9:20 AM
    Monday, February 6, 2012 10:25 AM
  • Hi Joe,
     
    How about the problem on your side? Do you still need any assistant about the problem? If you still show any concern on the problem, just feel free to let us know.
     
    Best Regards,

    Bruce Song [MSFT]
    MSDN Community Support | Feedback to us

    Wednesday, February 15, 2012 2:21 AM
  • Matthew Slyman M.A. (Camb.)

    I'm sorry, nothing too personal, chappy, but this is pretentious beyond belief. OMG, "Joe Blow, M.A" was bad enough, but then you add "(Camb.)"!!!

    As if these self-enlarging characters make the posting of an absurdly obvious suggestion about "debug.x" somehow more profound!  Crikey!  Really. If you were posting about the issue in the context of Literary History or Particle Theory, the big capital letters might seem a little less...hilarious!

    Why don't you a) either go the distance and append the impressive suffix with your god-forsaken GPA (and maybe include the square footage of your flat or perhaps the size of last year's bonus) or b) grow up and just be your regular old normal human self?




    Thursday, March 15, 2012 2:12 PM
  • Hey cool it man !!!

    Can't people big themseleves up any more?

    If you have got it, why not flaunt it?


    PG A bit of experimentation by trial and error often helps.

    Thursday, March 15, 2012 5:31 PM
  • Thanks, @Patrick!

    @blah:

    This information is simply part of my professional title. In my country (England), it's normal for professionals to write their name like this, at least in the context of professional communications. It would be misleading for me not to follow this convention: should I pretend to be less technically qualified than I really am? "M.A. (Camb.)" doesn't make me anything other than another fallible human being who happens to have a degree in computer science from an excellent university (denoting that I was once trained on many cutting-edge skills and principles, and have since forgotten some of them)... Nor does it automatically make my answers most correct for everyone. If my answers suit anyone, then I'm only pleased to have helped someone, after becoming personally acquainted with the frustration of "blocker issues" on many prior occasions.

    Another thing that I must question is your apparent suggestion that it's somehow more "pretentious" for me to use my real name and title with a profile that explains briefly who I really am, than for you to use a pseudonym that hides your true identity.

    Good luck to you!

    Note to moderators: you may delete this message with blah's original, if it suits you to delete either.


    Matthew Slyman M.A. (Camb.)

    Thursday, March 15, 2012 7:26 PM
  • Dear Matthew, blah, Patrick et al,

    For my part, having opened this thread I just would like to thank Matthew and everyone who weighed in on this topic. In this case and in many others, I have found the assistance of the kind people on this forum invaluable.  People are giving of their valuable time to help strangers with no compensation other than knowing they are helping.  Please respect that, respect others, and give in kind as you are able.

    Thank you all,

    Joe

    Sunday, March 18, 2012 8:06 AM