Opened 11 months ago

Closed 10 months ago

Last modified 10 months ago

#15565 closed defect (fixed)

[MSW] wxEVT_CHAR not triggered in wxGLCanvas

Reported by: koichi Owned by:
Priority: normal Milestone:
Component: wxMSW Version: stable-latest
Keywords: Cc:
Blocked By: Blocking:
Patch: no

Description

In my program, wxEVT_CHAR is processed in wxGLCanvas.
Since r74732, only a certain types of keys (combination of cursor keys and CTRL/SHIFT) trigger wxEVT_CHAR but other keys (alphabets and numbers) don't.

I know r74732 caused this problem but I still don't understand why.

Change History (4)

comment:1 Changed 11 months ago by vadz

Is the problem already reproducible in the isosurf sample? If not, could you please attach a minimal patch to this or cube sample allowing to debug it? TIA!

comment:2 Changed 10 months ago by vadz

  • Resolution set to worksforme
  • Status changed from new to closed

Cube sample works both out of the box and with this patch for me:

  • samples/opengl/cube/cube.cpp

    diff --git a/samples/opengl/cube/cube.cpp b/samples/opengl/cube/cube.cpp
    index b077760..4013792 100644
    a b int MyApp::OnExit() 
    308308 
    309309BEGIN_EVENT_TABLE(TestGLCanvas, wxGLCanvas) 
    310310    EVT_PAINT(TestGLCanvas::OnPaint) 
    311     EVT_KEY_DOWN(TestGLCanvas::OnKeyDown) 
     311    EVT_CHAR(TestGLCanvas::OnKeyDown) 
    312312    EVT_TIMER(SpinTimer, TestGLCanvas::OnSpinTimer) 
    313313END_EVENT_TABLE() 
    314314 

so I really need a way to reproduce the problem in order to do anything about it.

comment:3 Changed 10 months ago by koichi

The problem is not specific to the GLCanvas but I could only reproduce the bug with my own program.

There is certainly a case where WS_EX_CONTROLPARENT is set but not wxTAB_TRAVERSAL.
For example, some controls, such as wxStaticBoxSizer and wxNotebook, set WS_EX_CONTROLPARENT even when wxTAB_TRAVERSAL is not specified.

Then, most of keys except for a few navigation keys seem to be consumed by the following lines of a top level window of such controls because IsDialogMessage returns true for some reason.

2311 if ( m_hWnd != 0 && (wxGetWindowExStyle(this) & WS_EX_CONTROLPARENT) )
2312 {
...
2507 if ( ::IsDialogMessage(GetHwnd(), msg) )
2508 {
2509 IsDialogMessage() did something...
2510 return true;
2511 }
2512 }

So, I suspect that wxTAB_TRAVERSAL should still be checked in addition to WS_EX_CONTROLPARENT.

comment:4 Changed 10 months ago by VZ

  • Resolution changed from worksforme to fixed

(In [75061]) Restore the check for wxTAB_TRAVERSAL in wxMSW wxWindow code.

This check was replaced with a check for WS_EX_CONTROLPARENT in r74732 to
avoid using ::IsDialogMessage() when WS_EX_CONTROLPARENT is not set, but it
also resulted in using it when WS_EX_CONTROLPARENT is set but wxTAB_TRAVERSAL
is not.

Check for both of them now so that we only use IsDialogMessage() when we need
it (wxTAB_TRAVERSAL) and when it is safe to do it (WS_EX_CONTROLPARENT).

Closes #15565.

Note: See TracTickets for help on using tickets.