break on unhandled errors??!

[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!

[Allen Browne]

Re: break on unhandled errors??!

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" <PCESoft@PCESof t.invalidwrote in message
news:2slCj.992$ LV5.18@newssvr1 9.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!

[Larry Linson]

Re: break on unhandled errors??!

"Allen Browne" <AllenBrowne@Se eSig.Invalidwro te

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

[ARC]

Re: break on unhandled errors??!

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" <bouncer@localh ost.notwrote in message
news:XnnCj.2171 7$Qy3.20780@trn ddc03...

"Allen Browne" <AllenBrowne@Se eSig.Invalidwro te
>

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
>

[ARC]

Re: break on unhandled errors??!

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) & GetShortFileNam e(progpath & "update.exe ",
0, 0, SW_SHOWNORMAL


Shellexecute's code:

Public Declare Function ShellExecute Lib "shell32.dl l" Alias "ShellExecu teA"
(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_SHOWMINIMIZE D = 2
Public Const SW_SHOWMAXIMIZE D = 3
Public Const SW_SHOW = 5

Public Const MAX_PATH = 260

Public Declare Function GetShortPathNam e Lib "kernel32" Alias
"GetShortPathNa meA" (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" <bouncer@localh ost.notwrote in message
news:XnnCj.2171 7$Qy3.20780@trn ddc03...

"Allen Browne" <AllenBrowne@Se eSig.Invalidwro te
>

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
>

[lyle fairfield]

Re: break on unhandled errors??!

"ARC" <PCESoft@PCESof t.invalidwrote in
news:VwoCj.1745 1$0o7.10558@new ssvr13.news.pro digy.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\Xne ws.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.

[ARC]

Re: break on unhandled errors??!

Many thanks, Lyle! I'll give it a shot...Thanks for your reply.

[ARC]

Re: break on unhandled errors??!

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" <lylefa1r@yah00 .cawrote in message
news:Xns9A61464 656C51666664626 1@216.221.81.11 9...

"ARC" <PCESoft@PCESof t.invalidwrote in
news:VwoCj.1745 1$0o7.10558@new ssvr13.news.pro digy.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\Xne ws.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.
>
>

[ARC]

Re: break on unhandled errors??!

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" <lylefa1r@yah00 .cawrote in message
news:Xns9A61464 656C51666664626 1@216.221.81.11 9...

"ARC" <PCESoft@PCESof t.invalidwrote in
news:VwoCj.1745 1$0o7.10558@new ssvr13.news.pro digy.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\Xne ws.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.
>
>

[ARC]

Re: break on unhandled errors??!

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" <bouncer@localh ost.notwrote in message
news:XnnCj.2171 7$Qy3.20780@trn ddc03...

"Allen Browne" <AllenBrowne@Se eSig.Invalidwro te
>

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
>