I need to hide VB6 error dialogs, or better yet send the info to theapp.
event log.

When VB6 throws these dialogs they end up behind my front most (TOPMOST)
window an cannot be seen and make the system appear to be locked up.

Any Ideas on how to supress these messages?

Regards,
Aaron

You need to add error trapping (On Error statements) to trap the errors and
then handle them however you want.  You can write to the event log using
App.LogEvent, which works but has some limitations, or using the Windows
API.

Thanks for the response.  I already have relatively robust error handling
system implements that log errors to a DB and in the case of DB problems to
the event log.

My problem is that VB sometimes throws errors from from unexpected "Non-VB"
code.  You'll see this if your deep in and you look at the  'Call stack'.

I'm looking for a whole sale trap so I don't need to go through every line
of some 10K+ Lines in about 60 modules and add "on error resume next" to
every routine...

Anyone know about a Global way of absorbing these "Unhandled Errors"?

Regards,
Aaron

Show quoteHide quote

Show quote Hide quote There is no one simple mechanism. Instead you have to adopt a "Global
Strategy".

Take a look at this article as a good summary of the issues:
http://www.visibleprogress.com/vb_error_handling.htm
(I'm not promoting the product. I do highly recommend the free utility -
MZ-Tools:
http://www.mztools.com/v3/download.aspx)

Also it is helpful to adopt a strategy of "invariance". This means to simply
go through your code and validate your assumptions. Most errors are caused
by invalid data, thus do tests before you make the call.

The bad news: As you have discovered these are all things that should have
been addressed when you were developing these 10K lines and 60 modules.
Barring the availability of Mr. Peabody's Way Back machine - you have no
choice - but to take the time now to do what should have been done in the
first place.

The good news: Once you get started and develop a feel for what is needed,
and with a few tools like MZ-Tools the re-engineering can be done faster
than you might think. But more importantly - having now got burned - you
won't be making that mistake again. <g>

hth
-ralph

Show quote Hide quote I think the first step to managing errors is identify all "entry points" in your
code, and put error traps in them. These are mostly events, and Sub Main if you
use one. Any event that arises from the outside world (the OS) is a possible
entry point, meaning a place where your code can start running. Button clicks
are a simple example.

The key is to recognize that anytime the call stack shows "[ <Non-Basic
Code> ]", the code where it comes back into your app is a new entry point. The
classic example is a form load event, when the form is opened from another form:

' Form1
Private Sub Command1_Click()
Form2.Show
End Sub

'Form2
Private Sub Form_Load()
    Debug.Print "Break here"
End Sub

If you break on the debug statement, and view the call stack, you will see
Project1.Form2.Form_Load
[ <Non-Basic Code> ]
Project1.Form1.Command1_Click

This means that Form1.Command1_Click is an entry point, and also that
Form2.Form_Load is an entry point. Both need error traps. Other examples would
be Timer events and other control events that can start your code running.

If you put an error trap in every entry point, then you will never get an
unhandled VB runtime error. It is only a start to managing possible errors, and
you have to do more to really track them down, but this brings the beast under
control and is IMO the right place to start.

APSFlorida wrote:
LOL!  Blaming your tool, are ya?

Rewrite it right.

No idea on global error handler, but just an opinion: I would hate to use
any app (even my own) that sets any of it's windows to TOPMOST, it's really
anoying when they loose focus (or even the app looses focus) and the dam
window is still there :-)

Ivar

Ivar,

It's a Kiosk and by the way who asked for you opinion.  This is why new
groups are a poor excuse for actual technical support.

Regards,
Aaron


Show quoteHide quote

Then don't use them.  Or maybe you could provide relevent details up front
and not get testy when somebody makes an assumption.

You might also try elaborating on what actual errors you are getting.  I
can't remember the last time I got an error message from the "non-VB code"
(which I am quite aware of and was going to let your previous snide comment
pass until I saw this one as well).

Given that you are using the MS web interface I'm guessing that you are
pretty new to newsgroups (another assumption I'm afraid).  Perhaps you might
want to learn what they are about and how they work before you start
insulting people.

LOL!

A Kiosk app with limited Error-Handling????

Get a subscription to 2600. I have no doubt you will be able to find
additional "technical support" within its pages a few months after your
product's release. <g>

-ralph

Who asked for your question?

Well don't use them.

Mike

You did. It is implied by each and every post to a newsgroup.

Sorry I even tried to help.

Using Vista by any chance.
Vista has a habit of doing that when running from the VB6 IDE.

Show quoteHide quote

Visual Basic 2008 express - Index property on label
contents of picturebox contents get wiped out ...
How to find the datatype of a variable?
See the $99.00 Sendkeys replacment?
Print between two dates