Q How do I get the edit control keys Strg+C, Strg+X and Strg+V to work in my MFC application? I want to use your old FormSwap application (see the September 1998 and December 1998 issues of Microsoft® Systems Journal). I realized that the edit controls don't execute the shortcuts (Strg+X,V,C) although in a normal dialog-based application they do without any effort.Walter ReiserA First of all, since Walter hails from Austria, let me clarify that Strg is the standard computer abbreviation for the German word Steuerung, which means control; in English we say Ctrl-C, Ctrl-X, and so on. Well, now that you've suffered through your international awareness lesson, let me turn to Walter's question. The problem here is very simple. In my original FormSwap program, the main resource (.rc) file has the following entries: IDR_MAINFRAME ACCELERATORS PRELOAD MOVEABLE PURE BEGIN "C", ID_EDIT_COPY, VIRTKEY, CONTROL, NOINVERT "V", ID_VIEW_TEST, VIRTKEY, CONTROL, NOINVERT "X", ID_EDIT_CUT, VIRTKEY, CONTROL, NOINVERT ENDIn other words, the main app's accelerator table is overriding the control keys for the edit controls. So all you have to do is remove the three entries above and presto, the problem is solved. This is a common bug that creeps in when you copy code from one app to another. It doesn't happen with AppWizard-generated dialog apps because Visual Studio® is smart enough to omit the edit keys from the main accelerator table in the case of a dialog-based app. But if you copy the resource file from a normal (non-dialog-based) app, you can introduce this bug. The answer also reveals, by the way, one way to override the edit keys if you want to make them do something else: just bind the keys to new commands in your app's accelerator table. Of course, this would be most bizarre and even sadistic to your users: Ctrl-C, X, and V should always be Copy, Cut, and Paste, no matter what. But you might want to trap these keys in order to extend, rather than change, their behavior. I said the accelerator is one way to override the edit keys, implying that there are others. Indeed, accelerators aren't really even the best way to override edit keys in an edit control. Why not? Because they override the keys at the application or global level. In most cases, a more sensible and object-oriented way is to override the keys in the edit control itself, because conceptually the special behavior is usually a property of the edit control, not the application. If you want to use the same specialized behavior in another app, should you really have to modify the app's accelerator table and reimplement special commands? Wouldn't it be easier and make more sense to simply (re)use your already modified CSpecialEdit, or what-ever you called it, in the second app? Overriding the edit keys in an edit control is easy. Edit controls process these keys as ordinary WM_CHAR messages, not as accelerators, so all you have to do in this case is override WM_CHAR/OnChar. But that's if you want to override the keystrokes only (which would be rather strange), as opposed to the commands they invoke (Copy, Cut, Paste), which can come from either keyboard or context menu. In order to override the commands, you have to handle the WM_CUT, WM_COPY, and WM_PASTE messages. Got it?
Well, now that you've suffered through your international awareness lesson, let me turn to Walter's question. The problem here is very simple. In my original FormSwap program, the main resource (.rc) file has the following entries:
IDR_MAINFRAME ACCELERATORS PRELOAD MOVEABLE PURE
BEGIN
"C", ID_EDIT_COPY, VIRTKEY, CONTROL, NOINVERT
"V", ID_VIEW_TEST, VIRTKEY, CONTROL, NOINVERT
"X", ID_EDIT_CUT, VIRTKEY, CONTROL, NOINVERT
ENDIn other words, the main app's accelerator table is overriding the control keys for the edit controls. So all you have to do is remove the three entries above and presto, the problem is solved. This is a common bug that creeps in when you copy code from one app to another. It doesn't happen with AppWizard-generated dialog apps because Visual Studio® is smart enough to omit the edit keys from the main accelerator table in the case of a dialog-based app. But if you copy the resource file from a normal (non-dialog-based) app, you can introduce this bug.
The answer also reveals, by the way, one way to override the edit keys if you want to make them do something else: just bind the keys to new commands in your app's accelerator table. Of course, this would be most bizarre and even sadistic to your users: Ctrl-C, X, and V should always be Copy, Cut, and Paste, no matter what. But you might want to trap these keys in order to extend, rather than change, their behavior.
I said the accelerator is one way to override the edit keys, implying that there are others. Indeed, accelerators aren't really even the best way to override edit keys in an edit control. Why not? Because they override the keys at the application or global level. In most cases, a more sensible and object-oriented way is to override the keys in the edit control itself, because conceptually the special behavior is usually a property of the edit control, not the application. If you want to use the same specialized behavior in another app, should you really have to modify the app's accelerator table and reimplement special commands? Wouldn't it be easier and make more sense to simply (re)use your already modified CSpecialEdit, or what-ever you called it, in the second app?
Overriding the edit keys in an edit control is easy. Edit controls process these keys as ordinary WM_CHAR messages, not as accelerators, so all you have to do in this case is override WM_CHAR/OnChar. But that's if you want to override the keystrokes only (which would be rather strange), as opposed to the commands they invoke (Copy, Cut, Paste), which can come from either keyboard or context menu. In order to override the commands, you have to handle the WM_CUT, WM_COPY, and WM_PASTE messages. Got it?
但是ctrl+c不行