Amebis/wxWidgets
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Set the object for context menu events.

Browse Source 
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@50644 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Julian Smart
2007-12-11 15:30:34 +00:00
parent f99b00fabb
commit 5879692fb9
1 changed files with 44 additions and 43 deletions
Download Patch File Download Diff File Expand all files Collapse all files

47
src/mac/carbon/window.cpp
View File

@@ -454,7 +454,7 @@ static pascal OSStatus wxMacWindowControlEventHandler( EventHandlerCallRef handl
case kEventControlGetClickActivation : case kEventControlGetClickActivation :
{ {
// fix to always have a proper activation for DataBrowser controls (stay in bkgnd otherwise) // fix to always have a proper activation for DataBrowser controls (stay in bkgnd otherwise)
WindowRef owner = cEvent.GetParameter<WindowRef>(kEventParamWindowRef); WindowRef owner = cEvent.GetParameter<WindowRef>(kEventParamWindowRef);
if ( !IsWindowActive(owner) ) if ( !IsWindowActive(owner) )
{ {
@@ -605,7 +605,7 @@ pascal OSStatus wxMacUnicodeTextEventHandler( EventHandlerCallRef handler , Even
charBuf[ numChars - 1 ] = 0; charBuf[ numChars - 1 ] = 0;
#if SIZEOF_WCHAR_T == 2 #if SIZEOF_WCHAR_T == 2
uniChars = (wchar_t*) charBuf ; uniChars = (wchar_t*) charBuf ;
/* memcpy( uniChars , charBuf , numChars * 2 ) ;*/ // is there any point in copying charBuf over itself? (in fact, memcpy isn't even guaranteed to work correctly if the source and destination ranges overlap...) /* memcpy( uniChars , charBuf , numChars * 2 ) ;*/ // is there any point in copying charBuf over itself? (in fact, memcpy isn't even guaranteed to work correctly if the source and destination ranges overlap...)
#else #else
// the resulting string will never have more chars than the utf16 version, so this is safe // the resulting string will never have more chars than the utf16 version, so this is safe
wxMBConvUTF16 converter ; wxMBConvUTF16 converter ;
@@ -627,29 +627,29 @@ pascal OSStatus wxMacUnicodeTextEventHandler( EventHandlerCallRef handler , Even
UInt32 message = uniChars[pos] < 128 ? (char)uniChars[pos] : '?'; UInt32 message = uniChars[pos] < 128 ? (char)uniChars[pos] : '?';
/* /*
NB: faking a charcode here is problematic. The kEventTextInputUpdateActiveInputArea event is sent NB: faking a charcode here is problematic. The kEventTextInputUpdateActiveInputArea event is sent
multiple times to update the active range during inline input, so this handler will often receive multiple times to update the active range during inline input, so this handler will often receive
uncommited text, which should usually not trigger side effects. It might be a good idea to check the uncommited text, which should usually not trigger side effects. It might be a good idea to check the
kEventParamTextInputSendFixLen parameter and verify if input is being confirmed (see CarbonEvents.h). kEventParamTextInputSendFixLen parameter and verify if input is being confirmed (see CarbonEvents.h).
On the other hand, it can be useful for some applications to react to uncommitted text (for example, On the other hand, it can be useful for some applications to react to uncommitted text (for example,
to update a status display), as long as it does not disrupt the inline input session. Ideally, wx to update a status display), as long as it does not disrupt the inline input session. Ideally, wx
should add new event types to support advanced text input. For now, I would keep things as they are. should add new event types to support advanced text input. For now, I would keep things as they are.
However, the code that was being used caused additional problems: However, the code that was being used caused additional problems:
UInt32 message = (0 << 8) + ((char)uniChars[pos] ); UInt32 message = (0 << 8) + ((char)uniChars[pos] );
Since it simply truncated the unichar to the last byte, it ended up causing weird bugs with inline Since it simply truncated the unichar to the last byte, it ended up causing weird bugs with inline
input, such as switching to another field when one attempted to insert the character U+4E09 (the kanji input, such as switching to another field when one attempted to insert the character U+4E09 (the kanji
for "three"), because it was truncated to 09 (kTabCharCode), which was later "converted" to WXK_TAB for "three"), because it was truncated to 09 (kTabCharCode), which was later "converted" to WXK_TAB
(still 09) in wxMacTranslateKey; or triggering the default button when one attempted to insert U+840D (still 09) in wxMacTranslateKey; or triggering the default button when one attempted to insert U+840D
(the kanji for "name"), which got truncated to 0D and interpreted as a carriage return keypress. (the kanji for "name"), which got truncated to 0D and interpreted as a carriage return keypress.
Note that even single-byte characters could have been misinterpreted, since MacRoman charcodes only Note that even single-byte characters could have been misinterpreted, since MacRoman charcodes only
overlap with Unicode within the (7-bit) ASCII range. overlap with Unicode within the (7-bit) ASCII range.
But simply passing a NUL charcode would disable text updated events, because wxTextCtrl::OnChar checks But simply passing a NUL charcode would disable text updated events, because wxTextCtrl::OnChar checks
for codes within a specific range. Therefore I went for the solution seen above, which keeps ASCII for codes within a specific range. Therefore I went for the solution seen above, which keeps ASCII
characters as they are and replaces the rest with '?', ensuring that update events are triggered. characters as they are and replaces the rest with '?', ensuring that update events are triggered.
It would be better to change wxTextCtrl::OnChar to look at the actual unicode character instead, but It would be better to change wxTextCtrl::OnChar to look at the actual unicode character instead, but
I don't have time to look into that right now. I don't have time to look into that right now.
-- CL -- CL
*/ */
if ( wxTheApp->MacSendCharEvent( if ( wxTheApp->MacSendCharEvent(
focus , message , 0 , when , 0 , 0 , uniChars[pos] ) ) focus , message , 0 , when , 0 , 0 , uniChars[pos] ) )
@@ -3155,6 +3155,7 @@ void wxWindowMac::OnMouseEvent( wxMouseEvent &event )
wxContextMenuEvent evtCtx(wxEVT_CONTEXT_MENU, wxContextMenuEvent evtCtx(wxEVT_CONTEXT_MENU,
this->GetId(), this->GetId(),
this->ClientToScreen(event.GetPosition())); this->ClientToScreen(event.GetPosition()));
evtCtx.SetEventObject(this);
if ( ! HandleWindowEvent(evtCtx) ) if ( ! HandleWindowEvent(evtCtx) )
event.Skip() ; event.Skip() ;
} }