By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,466 Members | 2,171 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,466 IT Pros & Developers. It's quick & easy.

break on unhandled errors??!

P: n/a
ARC
Hello all,

I've noticed some funny things in my 2007 app lately, particularly where
it's not putting up errors when I know a field doesn't exist, etc.

In the VBA window, under Tools, Options, I was nearly 100% sure that I had
the "Break on All Errors" selected under error trapping. Now it's set to
"Break on Unhandled Errors", which I don't think is a good thing.

Case in point: I had a customer e-mail today about an Invoice showing blanks
where the tax should be. He said this has only happened once or twice, and
both times, restarting the program fixed the calculating of the tax. I would
just bet the error trapping setting is to blame, and if it was set to "break
on all errors", the user would have received an error box, rather than a
blank in the tax field.

Has anyone seen the Error Trapping option change on it's own before? I mean
for me, this is a "once set, then forget" type setting. I have not re-built
my code by re-importing into a blank project, as I know that would reset
lots of options. Any ideas? And is "Break on Unhandled Errors" as bad as I
think it sounds?

Thanks!

Mar 14 '08 #1
Share this Question
Share on Google+
9 Replies


P: n/a
Break on Unhandled Error is geneally the best setting to use.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"ARC" <PC*****@PCESoft.invalidwrote in message
news:2s**************@newssvr19.news.prodigy.net.. .
Hello all,

I've noticed some funny things in my 2007 app lately, particularly where
it's not putting up errors when I know a field doesn't exist, etc.

In the VBA window, under Tools, Options, I was nearly 100% sure that I had
the "Break on All Errors" selected under error trapping. Now it's set to
"Break on Unhandled Errors", which I don't think is a good thing.

Case in point: I had a customer e-mail today about an Invoice showing
blanks where the tax should be. He said this has only happened once or
twice, and both times, restarting the program fixed the calculating of the
tax. I would just bet the error trapping setting is to blame, and if it
was set to "break on all errors", the user would have received an error
box, rather than a blank in the tax field.

Has anyone seen the Error Trapping option change on it's own before? I
mean for me, this is a "once set, then forget" type setting. I have not
re-built my code by re-importing into a blank project, as I know that
would reset lots of options. Any ideas? And is "Break on Unhandled Errors"
as bad as I think it sounds?

Thanks!
Mar 14 '08 #2

P: n/a
"Allen Browne" <Al*********@SeeSig.Invalidwrote
Break on Unhandled Error is geneally the best setting to use.
For production, I agree, but Break on All Errors is often a good choice
during development and debug -- I am convinced I write cleaner code when I
avoid all but the errors that you just canNOT avoid with good code.

In any case, if Access itself is changing that user setting, it is an error.
If you can reproduce the behavior, you should report it to Microsoft, or at
least post it here.

Larry Linson
Microsoft Office Access MVP
Mar 14 '08 #3

P: n/a
ARC
Many Thanks, Larry.

If I see it again, I'll post if I have any clues. However, I do plan on
adding that to my list of double-checks prior to creating an .accde and
distributing. Oddly enough, I had one other setting change on it's own. The
setting for in access 2007, access options, current database, "Check for
Truncated # fields". This keeps turning itself on for no apparent reason. I
don't believe it does after a compact, or after creating an .mde, but not
sure what triggers the change. Strange stuff!
"Larry Linson" <bo*****@localhost.notwrote in message
news:XnnCj.21717$Qy3.20780@trnddc03...
"Allen Browne" <Al*********@SeeSig.Invalidwrote
Break on Unhandled Error is geneally the best setting to use.

For production, I agree, but Break on All Errors is often a good choice
during development and debug -- I am convinced I write cleaner code when I
avoid all but the errors that you just canNOT avoid with good code.

In any case, if Access itself is changing that user setting, it is an
error. If you can reproduce the behavior, you should report it to
Microsoft, or at least post it here.

Larry Linson
Microsoft Office Access MVP
Mar 14 '08 #4

P: n/a
ARC
One more question, Larry. I had a similar one in another thread. Windows
Vista doesn't seem to like this code. It works fine for xp users:

progpath = Left(datapath, lastpos)
progpath = progpath & "update.exe"
retval = Shell(progpath, 1)

I get a message that update.exe can't be found, even though it's there, and
progpath checks out. I suspect it's something to do with vista's extra
security for running .exe's, or possibly shell not being allowed on vista
(like the old winhelp).

I also tried using the lib:
ShellExecute 0, "open", Chr(34) & GetShortFileName(progpath & "update.exe",
0, 0, SW_SHOWNORMAL
Shellexecute's code:

Public Declare Function ShellExecute Lib "shell32.dll" Alias "ShellExecuteA"
(ByVal hwnd As Long, ByVal lpOperation As String, ByVal lpFile As String,
ByVal lpParameters As String, ByVal lpDirectory As String, ByVal nShowCmd As
Long) As Long

Public Const SW_HIDE = 0
Public Const SW_SHOWNORMAL = 1
Public Const SW_SHOWMINIMIZED = 2
Public Const SW_SHOWMAXIMIZED = 3
Public Const SW_SHOW = 5

Public Const MAX_PATH = 260

Public Declare Function GetShortPathName Lib "kernel32" Alias
"GetShortPathNameA" (ByVal lpszLongPath As String, ByVal lpszShortPath As
String, ByVal cchBuffer As Long) As Long

That reports an error as well, although I can use the above line to open
other types of files, like .txt, .html, etc.

Thanks again,

Andy
"Larry Linson" <bo*****@localhost.notwrote in message
news:XnnCj.21717$Qy3.20780@trnddc03...
"Allen Browne" <Al*********@SeeSig.Invalidwrote
Break on Unhandled Error is geneally the best setting to use.

For production, I agree, but Break on All Errors is often a good choice
during development and debug -- I am convinced I write cleaner code when I
avoid all but the errors that you just canNOT avoid with good code.

In any case, if Access itself is changing that user setting, it is an
error. If you can reproduce the behavior, you should report it to
Microsoft, or at least post it here.

Larry Linson
Microsoft Office Access MVP
Mar 14 '08 #5

P: n/a
"ARC" <PC*****@PCESoft.invalidwrote in
news:Vw*******************@newssvr13.news.prodigy. net:
One more question, Larry. I had a similar one in another thread.
Windows Vista doesn't seem to like this code. It works fine for xp
users:

progpath = Left(datapath, lastpos)
progpath = progpath & "update.exe"
retval = Shell(progpath, 1)

I get a message that update.exe can't be found, even though it's
there, and progpath checks out. I suspect it's something to do with
vista's extra security for running .exe's, or possibly shell not being
allowed on vista (like the old winhelp).
Shell is "allowed on VISTA."

This code works.

Sub wherever()
Dim path$
path = "C:\Program Files\Xnews\"
Shell path & "Xnews.exe"
End Sub

When I want to call "update.exe" I find the file with Explorer. I Right
Click on the file name and choose "Send To" -Desktop. This creates a
Desktop short-cut. I right Click on the short-cut and examine its
properties. The "Target" text box gives me the exact syntax to use with
Shell, i.e. "C:\Program Files\Xnews\Xnews.exe." I now have the syntax
that VISTA should like because VISTA created it.

When I get a path not found error it's usually because I try:

path = "C:\Program Files\Xnews"
Shell path & "Xnews.exe"

Using RetVal with Shell is worthwhile if you are going to do something
with RetVal such as save it and use it to close the opened process later.
Otherwise it's 11 wasted keystrokes for the coder and a wasted pointer at
runtime. Probably will cost you 0.0007 seconds.
Mar 14 '08 #6

P: n/a
ARC
Many thanks, Lyle! I'll give it a shot...Thanks for your reply.
Mar 14 '08 #7

P: n/a
ARC
Hi Lyle,

Just tried, and it's still returning error5, invalid procedure call or
argument.

I pasted in your code, the path variable is set to: c:\pc
experts\develop\IQOff2007\, and file is update.exe.

Interestingly, the code below successfully launches the .exe, but I get an
error when the .exe executes, that it can't read the .ini file, which also
resides in the same folder. It's like the folder is blocked by default?

ShellExecute 0, "open", progpath, 0, 0, SW_SHOWNORMAL


"lyle fairfield" <ly******@yah00.cawrote in message
news:Xn************************@216.221.81.119...
"ARC" <PC*****@PCESoft.invalidwrote in
news:Vw*******************@newssvr13.news.prodigy. net:
>One more question, Larry. I had a similar one in another thread.
Windows Vista doesn't seem to like this code. It works fine for xp
users:

progpath = Left(datapath, lastpos)
progpath = progpath & "update.exe"
retval = Shell(progpath, 1)

I get a message that update.exe can't be found, even though it's
there, and progpath checks out. I suspect it's something to do with
vista's extra security for running .exe's, or possibly shell not being
allowed on vista (like the old winhelp).

Shell is "allowed on VISTA."

This code works.

Sub wherever()
Dim path$
path = "C:\Program Files\Xnews\"
Shell path & "Xnews.exe"
End Sub

When I want to call "update.exe" I find the file with Explorer. I Right
Click on the file name and choose "Send To" -Desktop. This creates a
Desktop short-cut. I right Click on the short-cut and examine its
properties. The "Target" text box gives me the exact syntax to use with
Shell, i.e. "C:\Program Files\Xnews\Xnews.exe." I now have the syntax
that VISTA should like because VISTA created it.

When I get a path not found error it's usually because I try:

path = "C:\Program Files\Xnews"
Shell path & "Xnews.exe"

Using RetVal with Shell is worthwhile if you are going to do something
with RetVal such as save it and use it to close the opened process later.
Otherwise it's 11 wasted keystrokes for the coder and a wasted pointer at
runtime. Probably will cost you 0.0007 seconds.

Mar 14 '08 #8

P: n/a
ARC
One more thing, if I go into explorer and go to that folder, double-click
the update.exe file, it runs, checks the .ini and finishes perfectly.
"lyle fairfield" <ly******@yah00.cawrote in message
news:Xn************************@216.221.81.119...
"ARC" <PC*****@PCESoft.invalidwrote in
news:Vw*******************@newssvr13.news.prodigy. net:
>One more question, Larry. I had a similar one in another thread.
Windows Vista doesn't seem to like this code. It works fine for xp
users:

progpath = Left(datapath, lastpos)
progpath = progpath & "update.exe"
retval = Shell(progpath, 1)

I get a message that update.exe can't be found, even though it's
there, and progpath checks out. I suspect it's something to do with
vista's extra security for running .exe's, or possibly shell not being
allowed on vista (like the old winhelp).

Shell is "allowed on VISTA."

This code works.

Sub wherever()
Dim path$
path = "C:\Program Files\Xnews\"
Shell path & "Xnews.exe"
End Sub

When I want to call "update.exe" I find the file with Explorer. I Right
Click on the file name and choose "Send To" -Desktop. This creates a
Desktop short-cut. I right Click on the short-cut and examine its
properties. The "Target" text box gives me the exact syntax to use with
Shell, i.e. "C:\Program Files\Xnews\Xnews.exe." I now have the syntax
that VISTA should like because VISTA created it.

When I get a path not found error it's usually because I try:

path = "C:\Program Files\Xnews"
Shell path & "Xnews.exe"

Using RetVal with Shell is worthwhile if you are going to do something
with RetVal such as save it and use it to close the opened process later.
Otherwise it's 11 wasted keystrokes for the coder and a wasted pointer at
runtime. Probably will cost you 0.0007 seconds.

Mar 14 '08 #9

P: n/a
ARC
I see what's happening here... If you change the Error Trapping Option in
one access 2007 program, it changes it for ALL of your access programs...
"Larry Linson" <bo*****@localhost.notwrote in message
news:XnnCj.21717$Qy3.20780@trnddc03...
"Allen Browne" <Al*********@SeeSig.Invalidwrote
Break on Unhandled Error is geneally the best setting to use.

For production, I agree, but Break on All Errors is often a good choice
during development and debug -- I am convinced I write cleaner code when I
avoid all but the errors that you just canNOT avoid with good code.

In any case, if Access itself is changing that user setting, it is an
error. If you can reproduce the behavior, you should report it to
Microsoft, or at least post it here.

Larry Linson
Microsoft Office Access MVP
Mar 14 '08 #10

This discussion thread is closed

Replies have been disabled for this discussion.