This actually pertains to Visual Basic for Application in Access 2003, but I imagine that this forum should yield accurate information for a simple query such as this.

Naturally, the event in the title does not exist. Not for the pre-defined text box control in VB, anyway. However, it is what I'd like to capture.

I have a database that end-users use along side of a mainframe system. A few of the controls in the database forms contain fields that are more readable in one format, but required in another format for input into the mainframe. For example, an account number.

These fields contain dashes ("-") in order to make them more pleasing to the eye, however, when they copy the account and paste it into the mainframe, they can't have the dashes. So, I would like that if I have a field showing "123-45678-90", it would copy "1234567890".

This is easy enough to capture if the user uses Ctrl+C to copy. I'd imagine I could pick that up in the keypress event of the control, pull the clipboard, remove the dashes, and reapply. I don't know how to capture the event that the user highlights, right-clicks, and selects "Copy" from the menu. I considered the possibility of disabling this feature and implementing my own copy button (which would either be in the right-click list if I can add things to it or in an application menu above the form which I know I can do. I'm hoping, however, there is a way to actually capture the copy event, though.

So does anyone know a way to go about this?

You probably want to use the KeyUp event on the particular form on which the Ctl+C event occurs. You use this event to test for a combination of keys. You also need to enable the KeyPreview property on the form.

Private Sub Form_KeyUp(KeyCode As Integer, Shift As Integer)
Dim intKC as integer, intShift as Integer, intResult as integer

intKC = KeyCode
intShift = Shift
intResult = intKC + intShift

if intResult = 69 then
   ' Do whatever you want here
   Keycode = vbnullstring ' Disables the Control C functional 
                                        ' Replace it with your own.
end if
End Sub

The Shift Code has a value of either 1,2, or 4 when used in a key combination. C will be detected as 67 and the value of the control Key is 2 in the combination scenario.

Thanks, as I said in my original post, I can handle Ctrl-C on a key-press event. The problem is handing the right-click option. I don't want to leave any loose ends for the end-user to complain about when it goes into production.

but I imagine that this forum should yield accurate information for a simple query such as this.

Try the mousedown or mouseUP event. They are about the same as the KeyUP and KeyDown Events.

Private Sub Form_MouseDown(Button As Integer, Shift As Integer, X As Single, Y As Single)
Dim intButton as Integer
intButton = Button
Select case intButton
Case 1 ' Left Mouse Button

Case 2 ' Right Mouse Button
' Write Your Code Here
Case 4 ' Middle Mouse Button
'
Case Else
'
End Select
End Sub

The Shift parameter reflects whether the Shift, Ctl, or Alt key were pressed in conjunction with the Mouse Button: with values of 1, 2, and 4 respectively.

But this only covers for clicks on the Active Form. You might have to deal with Buttons, Pictures, etc. I don't know. And some of those controls may not have a built in MouseDown or MouseUp Event. That's where you'll have to get into the Window API's. It get's complicated fast.

I'm not talking about something spawned from a mouse-click event. This event doesn't tell you what you're clicking, it tells you where you're clicking. Even if the event fired when you click on the right-click context menu, which I think it doesn't. I'd have to determine where the Copy button was relative to the menu and the position on the screen, this can naturally vary because if someone does find a way to add or remove buttons from that menu, it will mess up the integrity of the code.

Thanks, again for your reply, however I don't think you are seeing the problem that I have.

I don't know how to capture the event that the user highlights, right-clicks, and selects "Copy" from the menu.

You can do that using the Windows API's and C Programming. Your problem is that you're in VB6. That's why they say, if you want finer grain control over what occurs in the program, you should use C or C++!

But I believe this is what you want: You need to write your own DLL in C to handle what you're asking, you need to register that into the VB6 Programming Environment so you can load it as a DLL from the Project Reference Menu, and then just use your DLL in VB6.

It's really simple, if you have 5 years experience in C Programming, 2 years programming Windows APIs, and a little patience: the patience of Job.

You can do that using the Windows API's and C Programming. Your problem is that you're in VB6. That's why they say, if you want finer grain control over what occurs in the program, you should use C or C++!

But I believe this is what you want: You need to write your own DLL in C to handle what you're asking, you need to register that into the VB6 Programming Environment so you can load it as a DLL from the Project Reference Menu, and then just use your DLL in VB6.

It's really simple, if you have 5 years experience in C Programming, 2 years programming Windows APIs, and a little patience: the patience of Job.

I think the suggestions that I provided are simplier and more portable than that. This is a distributed MDE. Do you really want me to package a DLL with it for some small copy feature?

Once again, I appreciate your assistance.

I think the suggestions that I provided are simplier and more portable than that. This is a distributed MDE. Do you really want me to package a DLL with it for some small copy feature?

Once again, I appreciate your assistance.

It is a small feature, but you have to catch the WindowMessages generated by the Windows operating system to avert the current behavior of the menu click and replace it with your own.

There are all kinds of Windows messages generated by a Windows program and that's just one of the messages. And you may not even be able to avoid that behavior, because that may be completely controlled by the executable file.

It's like a sandbox. You can play inside the sandbox, but you're not allowed to play outside that sandbox.

Visual Basic is just that: basic. What you're asking to accomplish goes beyond the basics.

It is a small feature, but you have to catch the WindowMessages generated by the Windows operating system to avert the current behavior of the menu click and replace it with your own.

There are all kinds of Windows messages generated by a Windows program and that's just one of the messages. And you may not even be able to avoid that behavior, because that may be completely controlled by the executable file.

It's like a sandbox. You can play inside the sandbox, but you're not allowed to play outside that sandbox.

Visual Basic is just that: basic. What you're asking to accomplish goes beyond the basics.

Yeah, believe me. I was taught on C++. I know all about event handling. This is not necessary and I'm not sure why you believe it is. I didn't ask to change how copy functionality, there is no need to do that. All you have to do is prevent the user from accessing the standard copy functionality in the form. There is three ways for them to do this. One is Ctrl+C which we know we can handle with a KeyUp event. They can access it from the top menu bar, which will be disabled in the MDE, so that's not an issue. The third way is right clicking on a control. To be completely blunt, I know that I can disable right-click and am willing to do it. So if you can't find anything simpiler than that, then there is no point in attempting it. The other alternative is if Access provides functionality to edit the right-click menu in VBA. I am almost positiive that they do. Anyway, don't concern yourself with this anymore, I might as well just review all the API documentation at this point to find what I'm looking for.

Thanks again.

I know all about event handling. This is not necessary and I'm not sure why you believe it is.

Windows is an event driven environment.

I know that I can disable right-click

I'd be interested in your future post about how you are able to do this.

I am almost positiive (sic) that they do.

If you knew, you wouldn't be saying almost. Almost only counts in horseshoes.

I don't know how to capture the event that the user highlights, right-clicks, and selects "Copy" from the menu.

You can't capture that in VB6 let alone from VBA. And I really doubt Access casts some magic functionality spell on VBA giving it more power than VB6.

I'll leave you alone.

Windows is an event driven environment.

Right, there is a huge difference between having events and having to handle them yourself. Regardless of how it's handle, there is an event when you press a key. I'm not trying to stop the event, I'm trying to avoid the user from being able to trigger the event.

I'd be interested in your future post about how you are able to do this.

Private Sub Form_Load()
    Me.ShortcutMenu = False
End Sub

Ta da.

If you knew, you wouldn't be saying almost. Almost only counts in horseshoes.

Almost means one thing. I have evidence and experience that leads me to be it's possible but I don't know how. It's why almost everything in science is a theory. It's because they're all almost positive that this is how things work.

You can't capture that in VB6 let alone from VBA. And I really doubt Access casts some magic functionality spell on VBA giving it more power than VB6.

Your replies make it glaringly obvious that you don't have much experience with Access. Do you not see the difference between working in a application and creating a stand-alone application? Everything in Access, the top menus, the right-click menus, the windows were defined by the code of Access. You can manipulate this as much as the developers of Access want you to manipulate it. ... and believe it or not, Windows allows almost everything to be manipulated.

I'll leave you alone.

Please do.

... Oh, and by the way. Thanks, again, for your help.

This article has been dead for over six months. Start a new discussion instead.