Message Box

[DS]

Where in this code does it say that when you go to delete a message box
pops up. I don't want the message box to pop up. I want to remove it
from his code. Thanks
DS

Private Sub Delete_Product_Click()
On Error GoTo Err_Delete_Product_Click
DoCmd.DoMenuItem acFormBar, acEditMenu, 8, , acMenuVer70
DoCmd.DoMenuItem acFormBar, acEditMenu, 6, , acMenuVer70

Exit_Delete_Product_Click:
Exit Sub

Err_Delete_Product_Click:
MsgBox Err.Description
Resume Exit_Delete_Product_Click

End Sub

[John Baker]

DS wrote:

Where in this code does it say that when you go to delete a message box
pops up. I don't want the message box to pop up. I want to remove it
from his code. Thanks

It's not what's in the code, it's what's NOT in it. Those messages are
generated by Access by default. If you never want to see them, you can
turn the option off in your preferences. If you just don't want to see
them while your application is running, issue this command:

DoCmd.SetWarnings (False)

before the offending code, and

DoCmd.SetWarnings (True)

afterwards.

[DS]

John Baker wrote:

DS wrote:

Where in this code does it say that when you go to delete a message
box pops up. I don't want the message box to pop up. I want to remove
it from his code. Thanks

It's not what's in the code, it's what's NOT in it. Those messages are
generated by Access by default. If you never want to see them, you can
turn the option off in your preferences. If you just don't want to see
them while your application is running, issue this command:

DoCmd.SetWarnings (False)

before the offending code, and

DoCmd.SetWarnings (True)

afterwards.

God Bless You.....It works great! I stuck it before and after the other
DoCmds. And it Works.....! Thanks.
DS

[Tim Marshall]

DS wrote:

God Bless You.....It works great! I stuck it before and after the other
DoCmds. And it Works.....! Thanks.
DS
DS wrote:
God Bless You.....It works great! I stuck it before and after the other
DoCmds. And it Works.....! Thanks.
DS

Be careful, though. If something does happen in the offending code
before you get to docmd.setwarnings true, and you don't have this
trapped in an on error procedure, then you could be in trouble.

Perhaps a better way is to deal with the confirmation message itself.

This is happening on a form, right? And the form is bound to a table?

Here's a good way to find out what is happening.

In your form properties is an event called "Before Delete Confirm".
Click the builder button and go to the VBA window and type in the following:

Private Sub Form_BeforeDelConfirm(Cancel As Integer, Response As Integer)

'No confirmation message on delete, so set response to:

Response = acDataErrContinue

End Sub

This is a much, much safer way of doing this. It is a good idea to
avoid docmd.setwarnings false and there are a lot of alternative ways
for various procedures to ensure no confirmation messages or other
events occur.

--
Tim - http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "What's UP, Dittoooooo?" - Ditto

[DS]

Tim Marshall wrote:

DS wrote:

God Bless You.....It works great! I stuck it before and after the
other DoCmds. And it Works.....! Thanks.
DS

DS wrote:

> God Bless You.....It works great! I stuck it before and after the other
> DoCmds. And it Works.....! Thanks.
> DS

Be careful, though. If something does happen in the offending code
before you get to docmd.setwarnings true, and you don't have this
trapped in an on error procedure, then you could be in trouble.

Perhaps a better way is to deal with the confirmation message itself.

This is happening on a form, right? And the form is bound to a table?

Here's a good way to find out what is happening.

In your form properties is an event called "Before Delete Confirm".
Click the builder button and go to the VBA window and type in the
following:

Private Sub Form_BeforeDelConfirm(Cancel As Integer, Response As Integer)

'No confirmation message on delete, so set response to:

Response = acDataErrContinue

End Sub

This is a much, much safer way of doing this. It is a good idea to
avoid docmd.setwarnings false and there are a lot of alternative ways
for various procedures to ensure no confirmation messages or other
events occur.

Thanks, I'll give it a try.
DS

[John Baker]

Tim Marshall wrote:

This is a much, much safer way of doing this. It is a good idea to
avoid docmd.setwarnings false

It would be a bad idea to set warnings to false when your application
starts and set it back to true when it exits.

But if you have any idea whatsoever what is going on during the
statements you're wrapping with the setwarning commands, there is
nothing "dangerous" about using them.

I submit that if you do not know what is going during the statements
that you would be wrapping them with, that *anything* you do while
coding is going to be dangerous.

[Trevor Best]

John Baker wrote:

Tim Marshall wrote:

This is a much, much safer way of doing this. It is a good idea to
avoid docmd.setwarnings false

It would be a bad idea to set warnings to false when your application
starts and set it back to true when it exits.

But if you have any idea whatsoever what is going on during the
statements you're wrapping with the setwarning commands, there is
nothing "dangerous" about using them.

I submit that if you do not know what is going during the statements
that you would be wrapping them with, that *anything* you do while
coding is going to be dangerous.

Nobody knows, because if an error occurs in an action query for
instance, you won't know about it because the warnings have been turned off.

In that instance, best to use ADO/DAO .Execute and (DAO) dbFailOnError
and wrap in a transaction.

In the OP's case, what I would do is use a delete query to delete the
current record then requery the form. I do this myself primarily because
I use SQL Server on the back end and it's the only way to get a
meaningful error message when it goes pear shaped.
--
Pretentious? Moi?