Opened 5 years ago

Closed 5 years ago

#15516 closed enhancement (fixed)

wxActivateEvent mouse click support

Reported by: Trigve Owned by:
Priority: low Milestone: future
Component: wxMSW Version: stable-latest
Keywords: wxActivateEvent WA_CLICKACTIVE mouse click Cc:
Blocked By: Blocking:
Patch: yes


Add support for finding out if wxActivateEvent has been done with mouse click. Currently supported only in MSW (

Attachments (3)

activate_mouse.patch download (2.1 KB) - added by Trigve 5 years ago.
activate_mouse.2.patch download (3.1 KB) - added by Trigve 5 years ago.
activate_mouse.3.patch download (3.2 KB) - added by Trigve 5 years ago.

Download all attachments as: .zip

Change History (10)

Changed 5 years ago by Trigve

comment:1 Changed 5 years ago by vadz

  • Priority changed from normal to low
  • Status changed from new to confirmed

Thanks for the patch, but it would be really great if it could conform a bit more to wx coding standards, notably the variable name should start with the lower letter, indentation seems to be wrong. Also, the documentation should mention the current limitation (MSW-only) as well as having a "@since 3.0" in it to indicate that this is a new method.

I also wonder if returning false from this method under other platform makes sense. I don't really know what is it used for anyhow, but I could see at least two other possibilities:

  1. Don't provide it under other platforms at all (then the accessor name should be changed to start with MSW prefix too).
  2. Return an enum { Mouse, Keyboard, Unknown } instead of a bool.

What do you think?

comment:2 Changed 5 years ago by Trigve

Thanks for reply,
about the wx coding standards - will incorporate it.

I forgot to mention my use case, sorry.

I'm using a main frame which has "menu" on left (custom drawn wxPanel based) and notebook on right. In notebook each page represent some module instance. Each module is solo process which use the notebook page as parent window. Then each module could show some dialogs which are modeless (because of enabling to switch to another running module in the notebook). When I alt+tab out from the application with focus on dialog and then alt+tab back the focus is moved to the main frame and not to dialog shown. But I needed to make the focus stay on dialog and only change focus to the main menu if I clicked with mouse to the main menu or with special key combinations. So I needed information if main frame was activated with mouse click or with something else.

My configuration is a bit complex because each tab in notebook represents solo process as I mentioned above and I needed to workaround some issues.

I've tried to solve it with functionality presented in wx, but unfortunately I couldn't implement it without this new addition to activate event.

Now about mentioned possibilities... I don't know if enum {...} with enumaraions you provided is best one because I know only if activate item was activated by mouse click or not. I don't have information by what type of "interfacing" was activate event sent (could be through keyboard, with activate function, meaybe something else?). So when using enum solution, then I propose only two enumerations, that is "Mouse" and "Other", i.e.




The bool solution is practically the same but without possible expansion, which enum method supports, for some new values in future if some activation method finding will be provided.

Anyway I don't think that the 2 possibilities you mentioned are mutually exclusive (could be enum solution but with MSW-only function).

I like that enum solution with Mouse and Other enumerations only. It looks more robust and could be extended in future if needed.

I don't know if marking the function as MSW-only is right step. What if in future some other platform will implement it, will be the MSWXXX() function get deprecated or removed?


comment:3 Changed 5 years ago by vadz

I think you might be able to do what you want in a portable way by handling wxEVT_LEFT_DOWN and just setting some flag there and checking it in your activation handler as WM_LBUTTONDOWN should be generated before WM_ACTIVATE IIRC.

If not, I'm find with enum ActivationReason { Activation_Mouse, Activation_Unknown } approach and if it does include Unknown (I prefer it to Other because it allows us to return it under other platforms without being downright misleading), then we could have this accessor for all platforms.


comment:4 Changed 5 years ago by Trigve

I've tried also the solution with wxEVT_LEFT_DOWN but without success. The event handler doesn't fire up. Don't know why and honestly haven't tried to investigate it much. But maybe will try.

I'm attaching the new patch. If you could look at it and tell me if is everything ok.

Thank you

Changed 5 years ago by Trigve

comment:5 Changed 5 years ago by vadz

Looks fine but the enum should be either prefixed with "wx" or nested into the class. I think the latter might be slightly better, perhaps we could call it wxActivateEvent::Reason and have Reason_XXX elements in it?

comment:6 Changed 5 years ago by Trigve

Enum moved to wxActivateEvent class and renamed to Reason. Also updated the constructor code for documentation (interface/wx/event.h).

Changed 5 years ago by Trigve

comment:7 Changed 5 years ago by VZ

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

(In [74915]) Add wxActivateEvent::GetActivationReason().

This method is implemented for wxMSW-only currently and allows to check
whether the window is being activated by a mouse click or in some other way

Closes #15516.

Note: See TracTickets for help on using tickets.