Strange behavior after macro conversion

[Captain Frog]

Hi!
I have a DB where I decided to convert some macro to VBA (delete, print, etc)
Those macro behaved OK before, but now after conversion I get an error message if try to cancel the action.
Runtime error 2501. The RunCommand was canceld.

When I use the macro button everything is fine but the VBA version of the same button fires this message.
I tried to catch the error message with:
cmdDeleteRecord_Click_Err:
If Err.Number = 2501 Then

Resume Next
But I still get the Error message

Any explanation

 

[theDBguy]

Are you able to post a sample db for testing?

 

[Gasman]

Have you got an On Error line? Otherwise it is not going to get to that code.

 

[tvanstiphout]

Hi!
I have a DB where I decided to convert some macro to VBA (delete, print, etc)
Those macro behaved OK before, but now after conversion I get an error message if try to cancel the action.
Runtime error 2501. The RunCommand was canceld.

When I use the macro button everything is fine but the VBA version of the same button fires this message.
I tried to catch the error message with:
cmdDeleteRecord_Click_Err:
If Err.Number = 2501 Then

Resume Next
But I still get the Error message

Any explanation

 

[tvanstiphout]

This is a normal error that gets raised when you (or your code) cancel certain actions, such as OpenForm or OpenReport.
That's why in Northwind Dev Edition's error handler, we wrote:
If lngError = 2501 Then Exit Sub '2501 = The OpenForm action was canceled. Not really an error.

BTW, I would HIGHLY recommend borrowing its error handling approach (see File > New for the templates including Northwind). You don't want to write code like this in individual event procedures; you'd want to write it at the global level. There is also a video where we explain our approach:

 

[Captain Frog]

Are you able to post a sample db for testing?

Well it would be a lot of work I would have to replace all the private data with anonymous one .

The error appears just after I get the usual warning from Acces: Relationship that specifies cascading delete are about to cause 1 record(s) in this table along with related record in related table to be deleted. Are you sure you want to delete these records?
If I click NO I get the error message.
Could this be that Access is at this moment not in VBA but running outside of VBA wich would explain that the error ist not catcht by "on error goto"?

 

[Gasman]

Just post the code segment (within code tags).

 

[Captain Frog]

Well it would be a lot of work I would have to replace all the private data with anonymous one .

The error appears just after I get the usual warning from Acces: Relationship that specifies cascading delete are about to cause 1 record(s) in this table along with related record in related table to be deleted. Are you sure you want to delete these records?
If I click NO I get the error message.
Could this be that Access is at this moment not in VBA but running outside of VBA wich would explain that the error ist not catcht by "on error goto"?

Sorry, I didn't realize how primitively Access had been programmed. That's exactly what's explained in the video.
Up until now I'd let Access take care of programming the basic navigation functions in a form to save time, but no more.
I have a solid error recovery system in all my other forms and reports. So I'm going to spend my weekend reprogramming all those little navigation buttons

 

[Captain Frog]

Just post the code segment (within code tags).

Sorry, I didn't realize how primitively Access had been programmed. That's exactly what's explained in the video.
Up until now I'd let Access take care of programming the basic navigation functions in a form to save time, but no more.
I have a solid error recovery system in all my other forms and reports. So I'm going to spend my weekend reprogramming all those little navigation buttons

This is a normal error that gets raised when you (or your code) cancel certain actions, such as OpenForm or OpenReport.
That's why in Northwind Dev Edition's error handler, we wrote:
If lngError = 2501 Then Exit Sub '2501 = The OpenForm action was canceled. Not really an error.

BTW, I would HIGHLY recommend borrowing its error handling approach (see File > New for the templates including Northwind). You don't want to write code like this in individual event procedures; you'd want to write it at the global level. There is also a video where we explain our approach:

Sorry, I didn't realize how primitively Access had been programmed. That's exactly what's explained in the video.
Up until now I'd let Access take care of programming the basic navigation functions in a form to save time, but no more.
I have a solid error recovery system in all my other forms and reports. So I'm going to spend my weekend reprogramming all those little navigation buttons

 

[Gasman]

Really. I think it is quite primitive to repeat yourself 3 times.