Do this by forwarding the events from wxDocParentFrame to wxDocChildFrame
first and forward them from there to wxDocManager which -- and this part
remains unchanged -- in turn forwards them to the active wxView which finally
forwards them to wxDocument. This requires another condition in the event
handling code as we still must forward from wxDocParentFrame to wxDocManager
itself if there are no active children at all, but this is the only way to
have the same event order in all cases, whether the event is originally
received by wxDocChildFrame or wxDocParentFrame.
Document this and add a unit test verifying that things indeed work like this.
Vadim Zeitlin [Sat, 4 May 2013 23:59:51 +0000 (23:59 +0000)]
Forward events to active child at MSW, not wx, level in wxMDIParentFrame.
We want to handle menu (and toolbar) events in the active MDI child before
handling them in the parent frame itself and the existing code achieved this
by forwarding wxEVT_MENU events at wx event processing level to the active
child. However this was not enough as the underlying MSW WM_COMMAND message
was still sent to the parent frame only and this could result in wx event not
being generated at all if the parent frame had a disabled menu item with the
same ID as (an enabled) item in the child frame, see #14314.
So forward WM_COMMAND directly to ensure that the correct window gets the
event in the first place. And this makes wxEVT_MENU forwarding in TryBefore()
unnecessary.
Vadim Zeitlin [Sat, 4 May 2013 23:59:43 +0000 (23:59 +0000)]
Add public wxDocManager::GetAnyUsableView().
This method tries to find the current view harder than GetCurrentView() and
always returns a non-NULL view if there are any open documents at all.
This is used by wxDocManager internally to find the view to apply the user
commands to and will also be needed in the upcoming changes outside of
wxDocManager, so just make this method public, as it seems that it could be
useful in user code too, especially if we could use some better fallback than
the first opened document (e.g. the last document the user interacted with
would be better).
This also clarifies the confusion between GetCurrentView() and GetActiveView(),
see #13296.
Vadim Zeitlin [Sat, 4 May 2013 23:59:40 +0000 (23:59 +0000)]
Use correct line numbers in assert failures in event propagation test.
Replace the calls to CheckMenuEvent() helper with ASSERT_MENU_EVENT_RESULT()
macro to allow passing the correct line number to cppunit assertion function,
otherwise the line number of CheckMenuEvent() was always used in case of
failure.
Vadim Zeitlin [Sat, 4 May 2013 23:59:37 +0000 (23:59 +0000)]
Consistently set wxMenuBar parent in all ports.
Previously, wxGTK used the associated frame as wxMenuBar parent, while the
other ports did not. Do set the frame as menu bar parent in all ports now.
Of course, considering that wxMenuBar is not a window at all, this doesn't
necessarily make much sense, but at least it makes the behaviour consistent.
Vadim Zeitlin [Sat, 4 May 2013 23:59:32 +0000 (23:59 +0000)]
Pass menu events to the handler in the associated menu bar.
We handled the menu events in the menu itself and the associated window, but
not in the menu bar that the menu belonged to. This was unexpected, so allow
handling the events in the menu bar itself too.
Vadim Zeitlin [Sat, 4 May 2013 23:59:29 +0000 (23:59 +0000)]
Fix menu event handlers calling order.
Pass the menu event to the window associated with the menu first, before
falling back on wxApp.
This required adding yet another flag to keep state in wxEvent but it seems to
be unavoidable as wxMenuBase::SendEvent() calls ProcessEvent() twice and we
must have some way to distinguish the first call from the second one.
Added a test case verifying that the menu events are indeed processed in the
expected order.
Vadim Zeitlin [Thu, 2 May 2013 22:08:19 +0000 (22:08 +0000)]
Mention using wxString::c_str() with vararg functions in the change log.
This is sufficiently important to be mentioned here in addition to the main
documentation. Especially considering that this results in run-time crashes
instead of (just) compile-time errors with MSVC.
Vadim Zeitlin [Wed, 1 May 2013 20:53:26 +0000 (20:53 +0000)]
Copy max width of wxGridCellTextEditor when cloning it.
Previously the max number of characters that could be entered into the editor
was lost when it was cloned, making it impossible to really limit the user
entry.
Remove the ctor from font flags added in r70445 as it's not needed any longer
now that we have this one and adding it resulted in compilation errors in the
existing code which compiled with 2.8 because of ambiguities between that ctor
and wxFont(int size, int family, int style, int weight. bool underlined, ...)
one, e.g.
Using wxDEFAULT as the font size in wxOSX resulted in creating 70pt font,
change this to use the normal font size instead for compatibility with the
other platforms.
Also allow using -1 as wxDEFAULT for compatibility with wxGTK, see #12541.
Fix assert when adding items with bitmaps wxBitmapComboBox.
The change of r73567 resulted in an assert when adding items with bitmaps to
wxBitmapComboBox without object client data. Fix the code added by this commit
to work for all kinds of client data, including wxClientData_None.
Really fix the problem with caret in wxGrid text editor under MSW.
The problem (see #11681) was due to not allowing the native control handle the
focus loss event. This, in turn, was due to the changes of r58969 which tried
to work around a crash which happened if the grid was destroyed from the code
of one of the user-defined event handlers called during the editor dismissal.
Fix both problems at once by calling event.Skip() in OnKillFocus() to let the
native handler have the event too and postponing the editor dismissal a little
by calling DisableCellEditControl() indirectly from a posted event handler
instead of immediately.
As this reverts the now unnecessary changes of r64646, it closes #15162.
wxOSX: store the menu title when inserting it in the menu bar.
We "lost" the menu title if the menu was inserted, and not appended, to the
menu bar, resulting wxMenuBar::GetMenuLabel[Text]() returning empty strings
for it in this case.
Test wxTE_PROCESS_ENTER in the combobox page of the widgets sample.
Remove the unused "File name" checkbox in this page and put "Process Enter"
one in its place to allow toggling wxTE_PROCESS_ENTER interactively to test
whether it works as expected.
Fix generic wxDataViewToggleRenderer hit testing with any alignment.
This change reverts the changes of r73835 and r73838 to
wxDataViewToggleRenderer::WXActivateCell() and instead fix the bug with mouse
hit testing in this function in the wxDataViewMainWindow::OnMouse() itself.
The problem there was that it offset the coordinates of the event differently
depending on whether the column alignment was set or left as default. Now
always make the coordinates relative to the item (not cell) rectangle for
compatibility with GTK+ native version, which is enough to make the original,
i.e. before the changes of r73835, code work.
Call LoadUrl() after associating our custom event handler with the browser
object as otherwise the wxEVT_WEBVIEW_LOADED event could be generated before
we were set up to catch it, resulting in the assertion failure inside
ENSURE_LOADED.
Fix wxEVT_DATAVIEW_COLUMN_HEADER_RIGHT_CLICK event type name.
Fix incorrect conflict resolution between the changes of r73823 and r73850:
the first renamed wxEVT_COMMAND_DATAVIEW_COLUMN_HEADER_RIGHT_CLICKED to
wxEVT_COMMAND_DATAVIEW_COLUMN_HEADER_RIGHT_CLICK while the latter renamed it
to wxEVT_DATAVIEW_COLUMN_HEADER_RIGHT_CLICKED. The proper new name is
wxEVT_DATAVIEW_COLUMN_HEADER_RIGHT_CLICK, use it instead.
Use the same short names as are used by the event table macros for the event
type constants themselves. This makes them much more comfortable to use, e.g.
Bind(wxEVT_BUTTON) compared to Bind(wxEVT_COMMAND_BUTTON_CLICKED).
The old long names are still kept for backwards compatibility and shouldn't be
removed as it doesn't really cost anything to continue providing them, but all
new event types should only use the short versions.
Small fixes after wxHtmlTagHandler::GetParser() addition.
Amend the changes of r73839:
- Don't use covariant return type for wxHtmlWinTagHandler::GetParser() as
VC6, which we still support, doesn't like it. Besides, this seems
unnecessary.
- Don't make GetParser() virtual at all as this doesn't appear to be necessary
neither.
- Add "@since 2.9.5" to the documentation of the new method.
Fix showing back hidden columns and rows in wxGrid.
While we don't support auto-sizing of the hidden columns and rows, we need to
still show them back when SetColSize() or SetRowSize() is called with -1
(a.k.a. wxGRID_AUTOSIZE) argument.
Really fix hit testing in the generic wxDataViewToggleRenderer.
The changes of r73835 fixed hit testing in horizontal direction but broke it
in the vertical one as the computed checkbox rectangle was not relative to the
cell rectangle as it should have been. Do fix this now.
Fix hit testing in generic wxDataViewToggleRenderer.
Handle clicks on the checkboxes in generic wxDataViewCtrl correctly by taking
into account that the checkbox rectangle is centred inside the total cell
rectangle.
Reset sorting column in generic wxDataViewCtrl properly.
We could keep using the column previously used for sorting even after
UnsetAsSortKey() was called on it. Ensure that this doesn't happen by
resetting the owner wxDataViewCtrl sort column index too.
Standardize on using "Added" instead of "Add" in the change log.
As all the other verbs were used in the infinitive and not past tense, do the
same thing for this one too, especially as we already had a mix of both forms.
Remove "ED" suffix from EVT_DATAVIEW_COLUMN_HEADER_RIGHT_CLICKED.
The naming of this macro was inconsistent with other similar macros in
wxListCtrl and wxTreeCtrl and even EVT_DATAVIEW_COLUMN_HEADER_CLICK in
wxDataViewCtrl itself. Moreover, it was even documented under the wrong name
without "ED".
Clear this mess by removing the "ED" suffix while still keeping the old macro
name for compatibility.
Add the simplest and most fool proof of chaining the pages in static wizards:
just chain several calls to the new, non-static, wxWizardPageSimple::Chain()
overload.
Use API_VERSION_NUMBER for debug help API version check.
This symbol is not documented but seems to be defined in all the existing
versions of imagehlp.h, so use it instead of relying on a hack with checkng
whether DBHLPAPI symbol is defined.
Check that files returned from wxDir::FindXXX() match the filter.
Native Windows functions used by wxDir check the filter against both the short
and the long name resulting in unexpected results, e.g. searching for
"foo.baz" would find "foo.bazaar".
Fix this by explicitly rechecking that we have a valid match ourselves.
By default the columns are auto-sized to fit just their label, which is fast
but not very user-friendly. Allow customizing this behaviour by handling the
(new) wxEVT_GRID_COL_AUTO_SIZE event.
Use LF eol-style svn property for all Unix-only files.
At least with some of them (e.g. tiffconf.h) using native EOLs under Windows
confuses MinGW/MSYS and results in build failures. As all these files are only
used under Unix or in Unix-like environments, use Unix EOLs for them
everywhere.
Fix wxTextEntryDialog::GetValue() when using SetTextValidator().
Associating a validator with the text control in wxTextEntryDialog resulted in
GetValue() always returning an empty string which was completely unexpected.
Fix this by setting the value string manually to avoid interfering with any
possibly used validators.
Václav Slavík [Wed, 3 Apr 2013 18:13:30 +0000 (18:13 +0000)]
Use the same wxDEBUG_LEVEL settings for Xcode projects as elsewhere.
Use the same debug flag default settings in the build/osx Xcode projects
as are used by all other makefiles and projects - that is,
wxDEBUG_LEVEL=1. This is done automatically by the headers, no need to
define any extra symbols when building.
Vadim Zeitlin [Sun, 31 Mar 2013 01:12:27 +0000 (01:12 +0000)]
Make wxToolBar styles consistent and add wxTB_DEFAULT_STYLE.
Don't include wxBORDER_NONE in neither wxToolBar ctor and Create() nor
wxFrame::CreateToolBar() flags parameter, override GetDefaultBorder() in
wxToolBar itself instead to use the border style appropriate for the current
platform by default. This has the same effect -- the default border style is
used unless another one is explicitly specified -- but is more clear and
consistent.
Also add wxTB_DEFAULT_STYLE for consistency with the other classes.
Vadim Zeitlin [Sun, 31 Mar 2013 01:12:21 +0000 (01:12 +0000)]
Remove wxTextCtrl::OnEnabled() hack from wxGTK.
Don't change the background colour when the control is being enabled or
disabled, it doesn't seem necessary and it's unclear why was this added by
r10179 in the first place. It does result in problems however as it could
somehow make the selection of wxTextCtrl invisible when it lost focus and so
fixes a serious usability problem which happened to all wxTextCtrls for which
a wxEVT_UPDATE_UI handler using wxUpdateUIEvent::Enable() was defined.
Vadim Zeitlin [Sun, 31 Mar 2013 01:12:15 +0000 (01:12 +0000)]
Explicitly trigger wxNotebook layout in wxMSW to ensure it is correct.
Due to an apparent bug in the native control implementation, space could be
reserved for the second row of tabs even when the notebook was big enough to
need it. Sending it an extra WM_SIZE seems to be enough to fix this.
Vadim Zeitlin [Sun, 31 Mar 2013 01:11:50 +0000 (01:11 +0000)]
Remove remaining occurrences of wxUSE_XPM_IN_MSW.
This symbol is not used since a very long time as XPM support is now always
available in wxMSW and most of its occurrences were removed almost 10 years
ago, just remove the remaining ones too.
Vadim Zeitlin [Fri, 29 Mar 2013 19:53:26 +0000 (19:53 +0000)]
Fix program not shutting down when using Ubuntu app menu.
Ensure that an idle event is generated after a menu event even when the latter
comes, via DBUS, from the out of process app menu and not from a real GTK menu.