Opened 10 years ago

Last modified 10 years ago

#4793 closed defect

Can no longer intercept paste event on wxTextCtrC

Reported by: rutgervaneerd Owned by:
Priority: normal Milestone:
Component: wxMSW Version:
Keywords: Cc: rutgervaneerd, vaclavslavik
Blocked By: Blocking:
Patch: no


In wxWidgets 2.8.0 for Windows it was possible to handle wxEVT_COMMAND_TEXT_PASTE for wxTextCtrl BEFORE the default processing (e.g. paste text to the control) was done. This way one could handle pasting manually (e.g. I used it to convert clipboard text to uppercase and write it to the control using WriteText()) and NOT perform the default pasting.

In wxWidgets 2.8.7 this is no longer possible. FIRST default pasting occurs, THEN I receive the wxEVT_COMMAND_TEXT_PASTE event. Because of this it is no longer possible to perform custom pasting (e.g. uppercase conversion, text/numeric conversion, etc.).

I found the following change in msw\textctrl.cpp. In wxWidgets 2.8.0, the WM_PASTE event is handled in wxTextCtrlWndProc. In 2.8.7 the WM_PASTE event is handled in MSWWindowProc.

This means that the WM_PASTE event is first handled by the default Windows handler in wxTextCtrlBase::MSWWindowProc() before wxTextCtrl::MSWWindowProc() can process the event, and generate a wxEVT_COMMAND_TEXT_PASTE event.

I consider this is a bug because a feature is lost (custom pasting). I assume someone tried to clean up message handling and this bug is an unwanted side effect.

Change History (1)

comment:1 Changed 10 years ago by vaclavslavik

This was already fixed:
T he bug was there for more than a year and will be fixed in 2.8.8. Please try latest SVN (2.8 branch) sources and reopen if it's still there (and if it is still present, include a patch against wx samples that allows us to reproduce it).

Note: See TracTickets for help on using tickets.