Opened 14 months ago

Closed 11 months ago

Last modified 11 months ago

#15345 closed defect (fixed)

dead keys troubles with wxRichTextCtrl on OS X

Reported by: noth Owned by: csomor
Priority: high Milestone: 3.0.0
Component: wxOSX-Cocoa Version: stable-latest
Keywords: wxRichText OSX accent Cc: minorinoki@…, csomor@…, mk@…
Blocked By: Blocking:
Patch: yes

Description

Hi,

It seems that some character are not supported on OS X.
All characters needing 2 keys for being entered are partially displayed with the accent missing.

When exporting the rich text buffer, the contents doesn't seems to contain a valid UTF8 string.

Example :

Type the following string "aâeêoô" on a wxRichTextCtrl, OS X platform.
The Control shows : "aaeeoo"
On Windows, the same code would show "aâeêoô".

Typing the same string on a wxTextCtrl would show the original string on both platforms. When pressing the accent character , the accent is displayed in yellow. When pressing the target character (eg e), the accent is applied to it.
On the wxRichTextCtrl, pressing the accent show nothing, and pressing the target only show the target character.

I don't think it's a problem with me, wrongly dealing with unicode. The rest of by code is working well and this problem only happens when typing in a wxRichTextCtrl. My library is build using --with-unicode.

Thanks for your help !

Attachments (2)

osxkeyevent.diff download (10.5 KB) - added by minoki 14 months ago.
Tweaks key event handling in OSX/Cocoa.
osxkeyevent2.diff download (10.4 KB) - added by minoki 14 months ago.
An updated version of the patch.

Download all attachments as: .zip

Change History (45)

comment:1 Changed 14 months ago by vadz

  • Milestone 3.0 deleted

I don't know about how does wxRichTextCtrl handle keyboard input so I can't unfortunately guarantee that this will be fixed in 3.0, sorry.

comment:2 Changed 14 months ago by noth

Sorry for the unjustified pressure on release 3.0 ! :)

comment:3 Changed 14 months ago by plorkyeran

wxSTC has the same issue on OS X, so I suspect that dead keys aren't being handled correctly in the key event logic rather than the control doing something wrong. I'll try to find time to investigate this further sometime soon.

comment:4 Changed 14 months ago by csomor

  • Summary changed from Accent troubles with wxRichTextCtrl on OS X to dead keys troubles with wxRichTextCtrl on OS X

it's the dead-keys, if the accented characters are entered without a dead-key on a corresponding native keyboard, then everything works perfectly, already the native events are delivered that way, probably a full NSTextInput implementation is needed to solve this properly...

Changed 14 months ago by minoki

Tweaks key event handling in OSX/Cocoa.

comment:5 Changed 14 months ago by minoki

  • Cc minorinoki@… added
  • Patch set

I've arranged a patch to fix this issue. This patch should also fix the similar problem with wxSTC.

Currently, wxOSX/Cocoa is not doing well with the input method; that is, the keyboard events are not properly passed to the input manager. Consequently, the input manager can't handle the dead keys.

This patch changes wxOSX/Cocoa to pass the key event to the input manager first, so the dead keys are correctly handled.

In this patch wxNSView adopts NSTextInput protocol, but most of the methods are stubs. It is a future task to add IME-related API to wx and implement the NSTextInput fully.

I don't touch wxOSX/Carbon because wxOSX/Cocoa is the way to go.

comment:6 follow-up: Changed 14 months ago by plorkyeran

Patch does fix dead keys in wxSTC. Kotoeri (the Japanese IME) actually seems to work other than that there's no UI for it, so it's rather hard to use. Non-text keypresses seem to be getting doubled (arrow keys move two letters at a time, backspace deletes two letters).

Changed 14 months ago by minoki

An updated version of the patch.

comment:7 in reply to: ↑ 6 Changed 14 months ago by minoki

Replying to plorkyeran:

Patch does fix dead keys in wxSTC. Kotoeri (the Japanese IME) actually seems to work other than that there's no UI for it, so it's rather hard to use.

Yes. Currently, 'preedit text' or 'composition string' is not handled at all. But this issue is about dead keys and I think the full support for the IME composition is another issue.

Non-text keypresses seem to be getting doubled (arrow keys move two letters at a time, backspace deletes two letters).

That was a simple mistake. I've attached an updated version of the patch.

comment:8 Changed 14 months ago by plorkyeran

Yes. Currently, 'preedit text' or 'composition string' is not handled at all. But this issue is about dead keys and I think the full support for the IME composition is ano

Yeah, I was just surprised that it worked at all as I was expecting it to be far more broken with how much isn't implemented.

Second patch doesn't have any obvious issues with wxSTC.

comment:9 Changed 14 months ago by noth

Updated patch tested on trunk revision and the problem is solved !
This also solves the issue with the exported rich text buffer (it was a consequence of the first one I guess).

Thanks a lot !

comment:10 Changed 14 months ago by vadz

  • Cc csomor@… added
  • Component changed from wxRichText to wxOSX-Cocoa
  • Milestone set to 3.0

I didn't have time to review the patch yet and I'm not sure if I really am qualified to do it but I think that if it fixes such an important bug, we should apply it for 3.0 nevertheless.

Stefan, could you please have a look and leave a note here if you have any objections? TIA!

comment:11 Changed 14 months ago by csomor

  • Owner set to csomor
  • Status changed from new to accepted

I'll look things through, as core key event handling is changed, I'll have to test the several situations to try to make sure we don't run into regressions

comment:12 Changed 14 months ago by SC

(In [74613]) first attempt at adding the minimal set needed for dead-key support, see #15345

comment:14 Changed 13 months ago by mojca

Even though the patch helps a tiny bit, users of wxMaxima report crashes after applying that patch (r74613). See the macports ticket linked above.

comment:15 Changed 13 months ago by csomor

  • Status changed from accepted to infoneeded

I need a sample, as the crash is occurring because of processing happening in BTextCtrl, I cannot easily reproduce it

comment:16 Changed 13 months ago by mk2013

  • Cc mk@… added

Hi, I am the original poster from MacPorts' trac.

Which info do you actually need apart from what was attached to https://trac.macports.org/ticket/38850?

Do I need to install wxWidgets in their debug variant to be able to deliver more sensible data for you?

Let me know how to help you.

comment:17 Changed 13 months ago by mk2013

  • Status changed from infoneeded to accepted

So, I've built the debug variant of the wxWidgets-3.0 port, but the crash log looks identical to https://trac.macports.org/attachment/ticket/38850/crashlog.txt.bz2.

It occurs at the moment when I enter the opening round parenthesis into the derivative dialog's expression edit field.

comment:18 Changed 13 months ago by csomor

  • Status changed from accepted to infoneeded

I need a minimal sample app - as small as possible - in source - that allows me to reproduce the crash, not a crash trace and not just a patch that solves the problem in your case.

I must try to apply fixes with as little collateral changes as possible, therefore I need to reproduce the original problem.

comment:19 Changed 13 months ago by mk2013

  • Status changed from infoneeded to accepted

I see. Oh, my goodness, I've never programmed anything using wxWidgets myself. I was just trying to use wxMaxima where I found the problem...

So, I guess I am not able to help you further with a self-coded minimal app regarding this error at the moment.

Sorry. :(

comment:20 Changed 12 months ago by vadz

  • Milestone 3.0 deleted
  • Status changed from accepted to infoneeded

AFAICS the original problem was fixed by r74613 and we don't have any way to reproduce the crash, so I'm not sure what are we supposed to do with this one...

comment:21 Changed 12 months ago by mk2013

Well, actually the original problem was NOT fixed by it.

But, I see that you cannot do much more here, because I am unable to come up with a little application demonstrating the actual problem.

I guess we have to leave this open for now as INFONEEDED, until someone can deliver such a minimal application.

BTW, if you could perhaps hint out where I could find code for a minimal wxWidgets application I could try it myself some time.

(But, I have never used wxWidgets myself, just found this to be a problem in wxMaxima.)

comment:22 Changed 12 months ago by vadz

I think the original problem was fixed, it's just that the fix has apparently created a new one. But it's really difficult for us to find it without being able to reproduce it...

The minimal wxWidgets application is here and the simplest way to get is to check out wxWidgets sources, either from svn or git, and build the sample using the provided makefile.

TIA for your help!

comment:23 Changed 12 months ago by mk2013

Thanks for the hint. I'll see what I can do to contribute to the bug hunting.

comment:24 follow-up: Changed 12 months ago by paulclinger

Vadim: I'm not sure what to do about the crash either, but I wouldn't remove the milestone. It would be very unfortunate not to be able to use international characters on OSX in wx3.0.

I'll build my app using the patched version and will check if I see any crashes. If nobody else can reproduce the crashes, I think we should merge the patch.

mk2013: One question for you; the stack trace from the crash looks similar to one issue I had in my application (unrelated to this fix) when I was using AddPendingEvent to queue an event. It would crash occasionally and only on OSX and win7 64bit, so I couldn't figure out what was causing it. It seems like it's more reproducible in your case, but is it possible that it is a different problem that surfaced after this fix was applied?

comment:25 in reply to: ↑ 24 Changed 12 months ago by mk2013

Replying to paulclinger:

mk2013: One question for you; the stack trace from the crash looks similar to one issue I had in my application (unrelated to this fix) when I was using AddPendingEvent to queue an event. It would crash occasionally and only on OSX and win7 64bit, so I couldn't figure out what was causing it. It seems like it's more reproducible in your case, but is it possible that it is a different problem that surfaced after this fix was applied?

No, the problem exists with and without the fix applied.

wxMaxima crashes on me as soon as I try to enter the opening bracket.

comment:26 Changed 12 months ago by mk2013

I have cloned wxWidgets using git.

In Xcode I started building minimal.app. Unfortunately the build stops with 4 errors:

1+2)

Ld build/Debug/libwx_osx_cocoa.dylib normal x86_64
cd /Users/marko/WC/GIT/wxWidgets/build/osx
setenv MACOSX_DEPLOYMENT_TARGET 10.5
/Developer/usr/bin/g++-4.2 -arch x86_64 -dynamiclib -L/Users/marko/WC/GIT/wxWidgets/build/osx/build/Debug -F/Users/marko/WC/GIT/wxWidgets/build/osx/build/Debug -filelist /Users/marko/WC/GIT/wxWidgets/build/osx/build/wxcocoa.build/Debug/dynamic.build/Objects-normal/x86_64/wx_osx_cocoa.LinkFileList -install_name @executable_path/../Frameworks/libwx_osx_cocoa.dylib -mmacosx-version-min=10.5 -framework WebKit -framework IOKit -framework Carbon -framework Cocoa -framework AudioToolbox -framework OpenGL -framework QTKit -lz -prebind -single_module -compatibility_version 3.0 -current_version 3.0.0 -o /Users/marko/WC/GIT/wxWidgets/build/osx/build/Debug/libwx_osx_cocoa.dylib

Undefined symbols:
  "wxThreadSpecificInfo::Get()", referenced from:
      wxLog::EnableThreadLogging(bool)  in log.o
      wxLog::EnableThreadLogging(bool)  in log.o
      wxLog::IsThreadLoggingEnabled()      in log.o
      wxLog::SetThreadActiveTarget(wxLog*)  in log.o
      wxLog::SetThreadActiveTarget(wxLog*)  in log.o
      wxLog::GetActiveTarget()      in log.o
      wxLog::OnLog(unsigned long, wxString const&, wxLogRecordInfo const&)in log.o
      wxTranslations::GetUntranslatedString(wxString const&)  in translation.o
  "wxThreadSpecificInfo::ThreadCleanUp()", referenced from:
      wxThread::CallEntry()     in threadpsx.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

3)

Ld build/Debug/minimal_cocoa.app/Contents/MacOS/minimal_cocoa normal x86_64
cd /Users/marko/WC/GIT/wxWidgets/samples/minimal
setenv MACOSX_DEPLOYMENT_TARGET 10.5
/Developer/usr/bin/g++-4.2 -arch x86_64 -L/Users/marko/WC/GIT/wxWidgets/samples/minimal/build/Debug -F/Users/marko/WC/GIT/wxWidgets/samples/minimal/build/Debug -filelist /Users/marko/WC/GIT/wxWidgets/samples/minimal/build/minimal_cocoa.build/Debug/dynamic.build/Objects-normal/x86_64/minimal_cocoa.LinkFileList -mmacosx-version-min=10.5 -framework WebKit -framework IOKit -framework Carbon -framework Cocoa -framework AudioToolbox -framework OpenGL -framework QTKit /Users/marko/WC/GIT/wxWidgets/build/osx/build/Debug/libwx_osx_cocoa.dylib -prebind -o /Users/marko/WC/GIT/wxWidgets/samples/minimal/build/Debug/minimal_cocoa.app/Contents/MacOS/minimal_cocoa

i686-apple-darwin10-g++-4.2.1: /Users/marko/WC/GIT/wxWidgets/build/osx/build/Debug/libwx_osx_cocoa.dylib: No such file or directory
Command /Developer/usr/bin/g++-4.2 failed with exit code 1

4)

PBXCp build/Debug/minimal_cocoa.app/Contents/Frameworks/libwx_osx_cocoa.dylib /Users/marko/WC/GIT/wxWidgets/build/osx/build/Debug/libwx_osx_cocoa.dylib
cd /Users/marko/WC/GIT/wxWidgets/samples/minimal
/Developer/Library/PrivateFrameworks/DevToolsCore.framework/Resources/pbxcp -exclude .DS_Store -exclude CVS -exclude .svn -exclude .git -strip-debug-symbols -resolve-src-symlinks /Users/marko/WC/GIT/wxWidgets/build/osx/build/Debug/libwx_osx_cocoa.dylib /Users/marko/WC/GIT/wxWidgets/samples/minimal/build/Debug/minimal_cocoa.app/Contents/Frameworks

pbxcp: libwx_osx_cocoa.dylib: No such file or directory

where the first one is the initial error.

I didn't expect that the minimal.app would build the whole wxWidgets library, but it tries to, obviously.
I thought I could let it use the wxWidgets already installed on my system. (1)

Still, I think the Xcode project build file seems to need some fixing!

Greets,
Marko

(1)

$ port installed wxWidgets-3.0 
The following ports are currently installed:
  wxWidgets-3.0 @2.9.5_1+debug (active)

comment:27 Changed 12 months ago by vadz

Unfortunately src/common/threadinfo.cpp is missing from the Xcode project. Adding it to the project should be enough to fix the link.

comment:28 Changed 12 months ago by mk2013

Hi vadz, although I added said fail to the project's src folder as an existing file - it appears now under "Implementation Files" as well - the errors still persist. Looks like my xcodeproj file is still not correct...

Can you perhaps make the corresponding change on github so that I can pull the correct file from there?

comment:29 Changed 12 months ago by mk2013

Oh, only now I see that this had actually already happened. Sorry for the false alarm. Just pulled in Dimitri's commit b2e8c6508f1825d and it worked. Now I could build successfully. Thanks. More later.

comment:30 follow-up: Changed 12 months ago by mk2013

Well, so much I can already say: the minimal app works out of the box, no problems at all.

What I need now is an example which makes use of an edit field and some key events just like those in wxMaxima which lead to a crash like this:

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00007fff5f3fff60
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   com.apple.CoreFoundation      	0x00007fff8113b2b4 __CFStringCreateImmutableFunnel3 + 20
1   com.apple.CoreFoundation      	0x00007fff81140356 CFStringCreateWithCharacters + 70
2   com.apple.Foundation          	0x00007fff83fb3dc3 -[NSPlaceholderString initWithCharacters:length:] + 17
3   com.apple.Foundation          	0x00007fff83fb3d92 +[NSString stringWithCharacters:length:] + 58
4   ...cocoau_core-2.9.5.0.0.dylib	0x00000001005ffbec -[NSEvent(OsGuiUtilsAdditions) charactersIgnoringModifiersIncludingShift] + 510
5   ...cocoau_core-2.9.5.0.0.dylib	0x00000001005ff516 wxWidgetCocoaImpl::SetupKeyEvent(wxKeyEvent&, NSEvent*, NSString*) + 378
6   ...cocoau_core-2.9.5.0.0.dylib	0x00000001005f9d7a wxWidgetCocoaImpl::DoHandleCharEvent(NSEvent*, NSString*) + 190
7   ...cocoau_core-2.9.5.0.0.dylib	0x00000001005ef23d -[wxNSTextFieldEditor insertText:] + 126
8   ...cocoau_core-2.9.5.0.0.dylib	0x00000001005ecd36 wxNSTextFieldControl::WriteText(wxString const&) + 248
9   ...cocoau_core-2.9.5.0.0.dylib	0x000000010057c488 wxTextEntry::WriteText(wxString const&) + 160
10  net.sf.wxMaxima               	0x0000000100082094 BTextCtrl::CloseParenthesis(wxString, wxString, bool) + 120
11  net.sf.wxMaxima               	0x0000000100082322 BTextCtrl::MatchParenthesis(int) + 224
12  net.sf.wxMaxima               	0x000000010008269f BTextCtrl::OnChar(wxKeyEvent&) + 29
13  libwx_baseu-2.9.5.0.0.dylib   	0x0000000100ba7ae9 wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) + 91
14  libwx_baseu-2.9.5.0.0.dylib   	0x0000000100ba8532 wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) + 124
15  libwx_baseu-2.9.5.0.0.dylib   	0x0000000100ba85d1 wxEvtHandler::TryHereOnly(wxEvent&) + 115
16  libwx_baseu-2.9.5.0.0.dylib   	0x0000000100ba9826 wxEvtHandler::TryBeforeAndHere(wxEvent&) + 48
17  libwx_baseu-2.9.5.0.0.dylib   	0x0000000100ba85fd wxEvtHandler::ProcessEventLocally(wxEvent&) + 27
18  libwx_baseu-2.9.5.0.0.dylib   	0x0000000100ba86d6 wxEvtHandler::ProcessEvent(wxEvent&) + 180
19  libwx_baseu-2.9.5.0.0.dylib   	0x0000000100ba889c wxEvtHandler::SafelyProcessEvent(wxEvent&) + 22
20  ...cocoau_core-2.9.5.0.0.dylib	0x00000001006a800e wxWindowBase::HandleWindowEvent(wxEvent&) const + 16
21  ...cocoau_core-2.9.5.0.0.dylib	0x0000000100559aa3 wxWindow::OSXHandleKeyEvent(wxKeyEvent&) + 229
22  ...cocoau_core-2.9.5.0.0.dylib	0x00000001005f9d9e wxWidgetCocoaImpl::DoHandleCharEvent(NSEvent*, NSString*) + 226
23  ...cocoau_core-2.9.5.0.0.dylib	0x00000001005ef23d -[wxNSTextFieldEditor insertText:] + 126
24  ...cocoau_core-2.9.5.0.0.dylib	0x00000001005ecd36 wxNSTextFieldControl::WriteText(wxString const&) + 248
25  ...cocoau_core-2.9.5.0.0.dylib	0x000000010057c488 wxTextEntry::WriteText(wxString const&) + 160

As you can see above wxMaxima tries to find the closing parenthesis while the user is typing (BTextCtrl::CloseParenthesis()), but then wxW's cocoau_core library messes things up.

I wonder how I could come up with a similar scenario in the to-be-made minimal test application.

comment:31 in reply to: ↑ 30 ; follow-up: Changed 12 months ago by vadz

  • Milestone set to 3.0
  • Status changed from infoneeded to accepted

Replying to mk2013:

I wonder how I could come up with a similar scenario in the to-be-made minimal test application.

You could try copying the handler from wxMaxime code in the minimal example and connecting it in the same way.

But perhaps you don't need to do this because, looking at the stack again, I think I see the reason for the crash now: it seems to happen simply because of infinite recursion. Indeed, the code calls wxTextEntry::WriteText() which results in BTextCtrl::OnChar() being called which calls wxTextEntry::WriteText() and so on forever (or, actually, until the stack is exhausted). The unclear thing to me here is why is OnChar() called in response to WriteText(). This really shouldn't happen if OnChar() is connected to wxEVT_CHAR event as I'd expect (and not, say, wxEVT_TEXT_CHANGED).

So it does look like a bug in wxOSX, calling insertText: programmatically must not result in DoHandleCharEvent() being called. But I don't know how to fix this without undoing r74945 entirely. We need to distinguish between our own calls to insertText: and calls to it from the IME. @minoki, any idea how to do this? I only see setting a flag before calling insertText: ourselves and checking it in wxWidgetCocoaImpl::insertText() but this is ugly and error prone...

However we need to either do this or to undo your patch entirely as this behaviour is really unexpected and risks breaking a lot of code.

comment:32 in reply to: ↑ 31 Changed 11 months ago by mk2013

Replying to vadz:

But I don't know how to fix this without undoing r74945 entirely. ...

However we need to either do this or to undo your patch entirely as this behaviour is really unexpected and risks breaking a lot of code.

Well, I want to underline that this crash occurred even before r74945 was introduced!!!

comment:33 Changed 11 months ago by vadz

It must have occurred for different reasons then as this code simply wasn't there before. Could you please try undoing r74945 (if you are using Git, it should be trivial, otherwise you can get the commit as a diff and apply it with patch -R), rebuild the library and wxMaxime and check what is the backtrace in that case? It should be quite different...

comment:34 Changed 11 months ago by mk2013

Well, I ran into the problem with wxMaxima using the 2.9.5, which is according to git

Create tag WX_2_9_5

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/tags/WX_2_9_5@74550 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775

at r74550 which is before the introduction of r74945!!'''

So, the crash you're seeing above is indeed provoked without the latter patch.

The patch I recall to have applied back then was r74613 (see https://trac.macports.org/ticket/38850#comment:13 ), so I guess the ball is back in my arena and I should try to apply r74945, i.e. use the most recent version of wxWidgets together with wxMaxima.

comment:35 Changed 11 months ago by mk2013

Trying to patch r74550 with r74945 wasn't possible, since the first of the four patch chunks failed.

I guess we'll have to install the latest git version of wxWidgets through MacPorts before proceeding with this.

Thanks for all your response so far and please stay patient.

comment:36 Changed 11 months ago by mk2013

I just upgraded to the latest wxWidgets version which supposedly contains the needed patches.

But I still see the crash.

Looking at the crash log however made clear that there is indeed an infinite recursion, as mentioned above by vadz!

See here the current state:

rocess:         wxmaxima [79998]
Path:            /Applications/MacPorts/wxMaxima.app/Contents/MacOS/wxmaxima
Identifier:      net.sf.wxMaxima
Version:         12.01.0 (12.01.0)
Code Type:       X86-64 (Native)
Parent Process:  launchd [116]

Date/Time:       2013-10-15 18:19:10.704 +0200
OS Version:      Mac OS X 10.6.8 (10K549)
Report Version:  6
Sleep/Wake UUID: 371677E3-343A-4800-93CC-D57A58729E45

Interval Since Last Report:          5324981 sec
Crashes Since Last Report:           306
Per-App Interval Since Last Report:  10730 sec
Per-App Crashes Since Last Report:   17
Anonymous UUID:                      4ADD88F0-37AC-4BFC-BB40-8308C8DB47A2

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00007fff5f3fff90
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   com.apple.CoreFoundation      	0x00007fff850452b4 __CFStringCreateImmutableFunnel3 + 20
1   com.apple.CoreFoundation      	0x00007fff8504a356 CFStringCreateWithCharacters + 70
2   com.apple.Foundation          	0x00007fff82694dc3 -[NSPlaceholderString initWithCharacters:length:] + 17
3   com.apple.Foundation          	0x00007fff82694d92 +[NSString stringWithCharacters:length:] + 58
4   ...x_osx_cocoau_core-3.0.dylib	0x000000010070193c -[NSEvent(OsGuiUtilsAdditions) charactersIgnoringModifiersIncludingShift] + 510
5   ...x_osx_cocoau_core-3.0.dylib	0x0000000100701266 wxWidgetCocoaImpl::SetupKeyEvent(wxKeyEvent&, NSEvent*, NSString*) + 378
6   ...x_osx_cocoau_core-3.0.dylib	0x00000001006fb636 wxWidgetCocoaImpl::DoHandleCharEvent(NSEvent*, NSString*) + 190
7   ...x_osx_cocoau_core-3.0.dylib	0x00000001006f0bb1 -[wxNSTextFieldEditor insertText:] + 126
8   ...x_osx_cocoau_core-3.0.dylib	0x00000001006ee6aa wxNSTextFieldControl::WriteText(wxString const&) + 248
9   ...x_osx_cocoau_core-3.0.dylib	0x000000010067ea1c wxTextEntry::WriteText(wxString const&) + 160
10  net.sf.wxMaxima               	0x000000010007c138 BTextCtrl::CloseParenthesis(wxString, wxString, bool) + 120
11  net.sf.wxMaxima               	0x000000010007c640 BTextCtrl::MatchParenthesis(int) + 224
12  net.sf.wxMaxima               	0x000000010007c9bd BTextCtrl::OnChar(wxKeyEvent&) + 29
13  libwx_baseu-3.0.dylib         	0x0000000100e8e827 wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) + 91
14  libwx_baseu-3.0.dylib         	0x0000000100e8f270 wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) + 124
15  libwx_baseu-3.0.dylib         	0x0000000100e8f30f wxEvtHandler::TryHereOnly(wxEvent&) + 115
16  libwx_baseu-3.0.dylib         	0x0000000100e9056e wxEvtHandler::TryBeforeAndHere(wxEvent&) + 48
17  libwx_baseu-3.0.dylib         	0x0000000100e8f33b wxEvtHandler::ProcessEventLocally(wxEvent&) + 27
18  libwx_baseu-3.0.dylib         	0x0000000100e8f414 wxEvtHandler::ProcessEvent(wxEvent&) + 180
19  libwx_baseu-3.0.dylib         	0x0000000100e8f5da wxEvtHandler::SafelyProcessEvent(wxEvent&) + 22
20  ...x_osx_cocoau_core-3.0.dylib	0x00000001007a7bca wxWindowBase::HandleWindowEvent(wxEvent&) const + 16
21  ...x_osx_cocoau_core-3.0.dylib	0x000000010065bd3d wxWindow::OSXHandleKeyEvent(wxKeyEvent&) + 229
22  ...x_osx_cocoau_core-3.0.dylib	0x00000001006fb65a wxWidgetCocoaImpl::DoHandleCharEvent(NSEvent*, NSString*) + 226
23  ...x_osx_cocoau_core-3.0.dylib	0x00000001006f0bb1 -[wxNSTextFieldEditor insertText:] + 126
24  ...x_osx_cocoau_core-3.0.dylib	0x00000001006ee6aa wxNSTextFieldControl::WriteText(wxString const&) + 248
25  ...x_osx_cocoau_core-3.0.dylib	0x000000010067ea1c wxTextEntry::WriteText(wxString const&) + 160
26  net.sf.wxMaxima               	0x000000010007c138 BTextCtrl::CloseParenthesis(wxString, wxString, bool) + 120
27  net.sf.wxMaxima               	0x000000010007c640 BTextCtrl::MatchParenthesis(int) + 224
28  net.sf.wxMaxima               	0x000000010007c9bd BTextCtrl::OnChar(wxKeyEvent&) + 29
29  libwx_baseu-3.0.dylib         	0x0000000100e8e827 wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) + 91
30  libwx_baseu-3.0.dylib         	0x0000000100e8f270 wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) + 124
31  libwx_baseu-3.0.dylib         	0x0000000100e8f30f wxEvtHandler::TryHereOnly(wxEvent&) + 115
32  libwx_baseu-3.0.dylib         	0x0000000100e9056e wxEvtHandler::TryBeforeAndHere(wxEvent&) + 48
33  libwx_baseu-3.0.dylib         	0x0000000100e8f33b wxEvtHandler::ProcessEventLocally(wxEvent&) + 27
34  libwx_baseu-3.0.dylib         	0x0000000100e8f414 wxEvtHandler::ProcessEvent(wxEvent&) + 180
35  libwx_baseu-3.0.dylib         	0x0000000100e8f5da wxEvtHandler::SafelyProcessEvent(wxEvent&) + 22
36  ...x_osx_cocoau_core-3.0.dylib	0x00000001007a7bca wxWindowBase::HandleWindowEvent(wxEvent&) const + 16
37  ...x_osx_cocoau_core-3.0.dylib	0x000000010065bd3d wxWindow::OSXHandleKeyEvent(wxKeyEvent&) + 229
38  ...x_osx_cocoau_core-3.0.dylib	0x00000001006fb65a wxWidgetCocoaImpl::DoHandleCharEvent(NSEvent*, NSString*) + 226
39  ...x_osx_cocoau_core-3.0.dylib	0x00000001006f0bb1 -[wxNSTextFieldEditor insertText:] + 126
40  ...x_osx_cocoau_core-3.0.dylib	0x00000001006ee6aa wxNSTextFieldControl::WriteText(wxString const&) + 248
41  ...x_osx_cocoau_core-3.0.dylib	0x000000010067ea1c wxTextEntry::WriteText(wxString const&) + 160
42  net.sf.wxMaxima               	0x000000010007c138 BTextCtrl::CloseParenthesis(wxString, wxString, bool) + 120
43  net.sf.wxMaxima               	0x000000010007c640 BTextCtrl::MatchParenthesis(int) + 224
44  net.sf.wxMaxima               	0x000000010007c9bd BTextCtrl::OnChar(wxKeyEvent&) + 29
45  libwx_baseu-3.0.dylib         	0x0000000100e8e827 wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) + 91

comment:37 follow-up: Changed 11 months ago by vadz

  • Priority changed from normal to high

I think there is some misunderstanding here. The problem due to r74945 hasn't been fixed yet, so it's expected that you (still) the crash due to infinite recursion. However in comment:32 you wrote that you had the crash even before it and what I was asking about was to try to rollback r74945 and check what happens then.

But we need to deal with the breakage introduced by r74945 in any case, of course. The trouble is that I still am not sure how to do it.

comment:38 in reply to: ↑ 37 Changed 11 months ago by mk2013

Replying to vadz:

However in comment:32 you wrote that you had the crash even before it and what I was asking about was to try to rollback r74945 and check what happens then.

Well, as I wrote in comment:34 the issue was already there in r74550.

comment:39 follow-up: Changed 11 months ago by paulclinger

I'm a bit confused by the last several messages, but FWIW, the keys are working correctly for me and I haven't (yet) seen any crashes related to brace matching. I even tried similar logic with auto-adding characters (I'm using wxSTC), but everything works fine.

mk2013, I recently run into somewhat similar issue (with infinite recursion related to event being repeatedly called) and avoided it by wrapping my call into SetEvtHandlerEnabled(false) and SetEvtHandlerEnabled(true). Maybe you can explore it (at least as a workaround).

comment:40 in reply to: ↑ 39 Changed 11 months ago by mk2013

Replying to paulclinger:

Maybe you can explore it (at least as a workaround).

My problem is that I cannot even create a minimal app reproducing this infinite recursion bug myself. I just observed it happening with wxMaxima.

comment:41 Changed 11 months ago by vadz

Actually there is already such a flag (see comment:31) in the code, it's called wxMacEditHelper. So we should just use it here too and doing it seems to solve the problem without breaking anything else, so I'm going to commit this.

For the record, here is a patch I used to reproduce the problem:

  • samples/minimal/minimal.cpp

    diff --git a/samples/minimal/minimal.cpp b/samples/minimal/minimal.cpp
    index a78e462..fd1ebd9 100644
    a b bool MyApp::OnInit() 
    141141// main frame 
    142142// ---------------------------------------------------------------------------- 
    143143 
     144wxTextCtrl* g_text; 
     145 
     146void OnTextChar(wxKeyEvent& event) 
     147{ 
     148    if ( event.GetKeyCode() == 'a' ) 
     149        g_text->AppendText("aa"); 
     150    else 
     151        event.Skip(); 
     152} 
     153 
    144154// frame constructor 
    145155MyFrame::MyFrame(const wxString& title) 
    146156       : wxFrame(NULL, wxID_ANY, title) 
    MyFrame::MyFrame(const wxString& title) 
    172182    CreateStatusBar(2); 
    173183    SetStatusText("Welcome to wxWidgets!"); 
    174184#endif // wxUSE_STATUSBAR 
     185 
     186    g_text = new wxTextCtrl(this, wxID_ANY, ""); 
     187    g_text->Bind(wxEVT_CHAR, OnTextChar); 
    175188} 
    176189 
    177190 

Before my changes, pressing 'a' in the control was enough to crash the program because of the infinite recursion.

comment:42 Changed 11 months ago by VZ

  • Resolution set to fixed
  • Status changed from accepted to closed

(In [75046]) Avoid sending wxEVT_CHAR events when text is inserted by the program in wxOSX.

This should fix crashes due to infinite recursion in the code that calls
wxTextCtrl::WriteText() from wxEVT_CHAR handler.

Closes #15345.

comment:43 Changed 11 months ago by mk2013

Herewith I verify that committed change fixes the infinite recursion issue in wxMaxima.

Thanks for fixing this!

Note: See TracTickets for help on using tickets.