Click here to Skip to main content
15,040,212 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Using wxWidgets, I have a wxWindow, with a wxWindow child window.

If I disable the child window with EnableWindow(false), or Disable(), the parent window gets the mouse messages in Windows, but it does not work in Linux. In Linux the parent does not receive the mouse messages.

What can I do to make a mouse click be sent to the parent in Linux when the child window is disabled?

I am using wxWidgets-2.8.12

I have exactly the same wxWidgets code. When I run it in Windows, I get the event in the parent window when I click on a disabled window. When I run it in Linux the parent does not get the event.
Updated 31-Jan-13 9:40am
Sergey Alexandrovich Kryukov 31-Jan-13 13:23pm
Why do you think it should? :-)

1 solution

Why do you think a disabled window should handle any input? Disabled is disabled, it should not do it. Just review your code design. You should handled the user input to the currently active window, and an active windows is always enabled, otherwise it is not active.

Patty7 31-Jan-13 13:58pm
What I really have is a wxPanel, with my wxWindow derived class children, let's call it "Class1".

"Class1" is serves as a base class for any window with any type of Control in it, for example a wxGrid or wxTextCtrl, or my own painted window.

My Class1 handles all mouse events for any type of child windows derived from it, it also allows me to overpaint whatever I want over the controls. It handles all the drag, resize, overpaint, etc.

When I switch my "Class1" window to "configurable" mode, the control is disabled and I can drag, move, resize, and overpaint in Windows.

I did not want to use bitmaps on painting, resizing, etc, for several reasons, but if this is the only way I guess I will need to do it. I was thinking that there could be a way like in Windows, to pass the keyboard input messages to the parent when the window was disabled. This works fine in Windows, but not in Linux.
Sergey Alexandrovich Kryukov 31-Jan-13 14:06pm
With Windows, this is also not how it works. The application (usually) has only one common event/message loop. Raw (hardware) input are dispatched to this loop based on active window; and the keyboard input events is dispatched based on the keyboard focus, which is also a control of an active window. If you disable/hide a window, it always becomes inactive. You are missing something very basic. Multi-window UI is not a problem, no matter if it's wxWidgets, GTK+, Windows, CLR or something. However, it's usually much better to develop a single-window application, where the role of separate windows play some controls: tab pages, docked panels, etc.
Patty7 31-Jan-13 14:45pm
I tested in Windows, and it does work fine in Windows.
From Windows documentation:
"Messages : The system passes a child window's input messages directly to the child window; the messages are not passed through the parent window. The only exception is if the child window has been disabled by the EnableWindow function. In this case, the system passes any input messages that would have gone to the child window to the parent window instead. This permits the parent window to examine the input messages and enable the child window, if necessary"
Sergey Alexandrovich Kryukov 31-Jan-13 14:50pm
Then maybe I did not get what exactly are you doing. You can send messages to disabled/hidden/non-active window, and it will handle then in its window function, but OS won't dispatch raw input to the disabled window. Do you see the difference?
Now, what exactly did you try?
Sergey Alexandrovich Kryukov 31-Jan-13 14:56pm
Wait a minute! Also, there are different meanings of the term "window". In raw Windows API terminology, this is any object with Window handle, that is, it can be a top-level (so called POPUP, in Windows API jargon), or the child, as a control. I thought you are only talking about top-level windows, until I saw the words "to the parent window instead". For the top-level windows, the child-parent relationship is made effectively defunct and should not be used (but it can be violated, to get ugly effect of a window, with its non-client areas, in another window — don't do it, by the way).

Nevertheless, I believe all I said so far is still valid, but check it up, taking it into account.

Anyway, now I cannot see what exactly did you try with Windows and wvWidgets and was it analogous or not...
Patty7 31-Jan-13 15:31pm
Thank you for your time. I have exactly the same wxWidgets code. When I run it in Windows, I get the event in the parent window when I click on a disabled window. When I run it in Linux the parent does not get the event.
Sergey Alexandrovich Kryukov 31-Jan-13 15:42pm
As you did not provide any code, this is not so helpful. Besides, no, Windows and wxCode hardly can be identical, can it? :-)
Patty7 31-Jan-13 16:24pm

MyPanel(wxWindow* parent, wxWindowID id = wxID_ANY, const wxString& title = wxT(""), const wxPoint& pos = wxDefaultPosition, const wxSize& size = wxDefaultSize,

MyPanel .cpp :

MyPanel::MyPanel(wxWindow* parent, wxWindowID id, const wxString& title,
const wxPoint& pos, const wxSize& size, long style)
: wxPanel(parent, id, pos, size, style, title)
wxWindow *pWnd3 = new wxWindow(this, wxID_ANY, wxPoint(220,220), wxSize(100, 100));

void MyPanel::OnMouseLeftDown(wxMouseEvent &event)
// when running in Windows of course the event.Object is the MyPanel window as I expected.
int ltest;
ltest = 1;

If I set a break point on the OnMouseLeftDown method.
if I run the program and click on the child window area on the screen, in Windows it hits the break point, in Linux it does not.
Thank you.
Sergey Alexandrovich Kryukov 31-Jan-13 17:14pm
Well, of course, if you disable pWnd3, which handles events according to BEGIN_EVENT_TABLE shown in MyPanel.cpp, it won't handle LEFT_DOWN even, but not because it does not handle events, but because OS won't dispatch events to this window. Do you see the picture? And I tell you, if you do analogous experiment in Windows, you won't get those events as well. If you say "it works in Windows", I'll answer: no, it wasn't "it", it was something different. If you show Windows code, I'll probably be able to explain why it "works".

Again, I don't understand why are you trying to do this: working with disabled windows, etc. As I say, you rather need to review your design...

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
Top Experts
Last 24hrsThis month

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900