Add a method allowing creation of a wxMenu object from a native menu handle.
This will be used to implement access to the system menu in an upcoming commit
but could also be useful for other purposes.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68595 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The workaround for a bug in g++ 3.5 breaks compilation with 4.7 which
implements two-phase lookup correctly, so disable this workaround for 4.7 and
later. We could probably even only enable it for 3.x but this doesn't really
matter as previous 4.x releases don't have problems with this anyhow.
Closes#13385.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68594 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
g++ (usefully) warns when assigning NULL to a non-pointer in wxGDIPlusRenderer.
Just use 0 instead of NULL to avoid the warning.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68586 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This method used to work in 2.8 but was unimplemented in 2.9.
Restore more or less the old implementation using the data that we already
have in wxMimeTypesManager anyhow.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68563 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Implement support for wxHELP for wxMSW, wxGTK and wxOSX/Cocoa (at least when
showing the message box from the main thread, there doesn't seem to be any way
to show more than three buttons with CFUserNotificationDisplayAlert() so
"Help" button is not supported when using it).
This is useful not only on its own, i.e. to allow the user to ask for help,
but also because it brings the total number of buttons supported by the
message dialog to 4, meaning that more choices can be offered to the user
(which is rarely, but not quite never, useful).
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68537 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxWindow might not be fully declared in dcbase.cpp but we need its full
declaration for wxDCImpl::InheritAttributes() so explicitly include
wx/window.h -- while this is usually already included from somewhere else it
might not be in minimal builds with a lot of features disabled.
Closes#13380.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68522 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxFindWindowAtPoint() only returns wxWindowMSW, not the derived wxWindow, in
wxUniv build so assign its return value to wxWindowMSW to avoid compilation
problems in it.
Closes#12534.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68520 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Using "i.e." in the brief Doxygen comment makes it end it after the second
period and results in truncated brief description and an unwanted line break
in the full description.
Just avoid using periods for now inside the brief description. Maybe a better
solution could be found in the future.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68519 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The keyboard navigation code correctly checked that TAB was not propagated
above the TLW containing the window in which the key was pressed to avoid
switching focus between different TLWs by pressing TAB.
However wxMDIChildFrame is not a TLW and so it was possible to switch focus
between two different MDI child frames by pressing TAB. This was unexpected
and counterintuitive, especially because the frame receiving focus was not
even activated (which might be another bug).
Fix this by adding a new wxWindow::IsTopNavigationDomain() virtual method that
can be overridden to indicate that a window is a self-contained "keyboard
navigation domain" and that keyboard events shouldn't propagate outside of it
and override it in both wxTopLevelWindow and wxMDIChildFrame to ensure that it
behaves correctly.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68502 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
"focussed" spelling is unusual and inconsistent with "focused" used in many
other places in the same file, so renamed "focussed_child_of_parent" and also
use standard camelCase naming convention for it.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68501 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Calling Iconize(false) on a maximized window restored it to its normal state
instead of doing nothing as expected.
Return immediately from Iconize() if the requested state is already the
current one to avoid it.
Closes#13373.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68493 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
When wxSocket::WaitForAccept() was called from another thread or on a socket
with wxSOCKET_BLOCK flag it didn't work because it called
wxSocketImpl::Select() with wxSOCKET_CONNECTION_FLAG which was only handled
for the client sockets in this function.
Handle it now for the server ones too, this should allow blocking server
sockets to work again.
Closes#12836.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68492 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
libstdc++ (which is used by Clang) defines numeric_limits<> as a struct
and Clang issues a warning about our specialization that uses 'class'.
As libstdc++ developers have no intention of fixing this, silence the
Clang warning by using 'struct' for it.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68472 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Even Clang++ shipped with Xcode 4.1 still can't handle visibility
of non-inline methods in exported template classes if the default
visibility is 'hidden'.
Disable visibility support for Clang for now, we'll revisit it in the future.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68471 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The keyboard keys not corresponding to real characters, such as cursor arrows
or function keys, must generate wxKeyEvents with WXK_NONE as Unicode key code
to make it possible to distinguish them from the printable characters but
wxOSX generated events with valid Unicode key codes for them instead.
Avoid this by excluding Unicode key codes corresponding to code points in the
Unicode private use area: while this doesn't seem to be documented anywhere,
all non-printable characters seem to have their Unicode representation inside
it.
This change brings wxOSX keyboard event generation in line with the other
ports and, as a side effect, also closes#12423.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68467 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
A wxEVT_KILL_FOCUS event was generated when wxTextCtrl::WriteText() was called
in wxOSX, even though the control didn't lose focus at all in this case. This
was completely unexpected and thoroughly confused wxGrid code which closed the
in place editor immediately after showing it because of this (this was perhaps
only the case since r68319 but the changes there were correct so they only
masked the real bug).
Avoid this bogus event by remembering the NSView currently being
programmatically modified and not doing anything in textDidEndEditing
notification if it is generated for this view.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68466 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
First, enable execution of the Lines() wxTextCtrl unit test case under wxOSX
as it passes since the fix in the previous commit.
Do add a test for GetNumberOfLines() that currently doesn't work in the same
way under all platforms -- but with this test we at least can be sure how does
it work exactly where.
Also mention the current discrepancy in this function behaviour in the
documentation.
See #12366.
Fix Lines() wxTextCtrl unit test to pass under wxGTK too.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68465 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
No modifiers were used for stock accelerators, i.e. Append(wxID_NEW) resulted
in an item with the label "New" and plain "N" as accelerator in wxOSX. This
was due to wxACCEL_CMD not being handled in wxAcceleratorEntry::ToString() so
map it to the same prefix as wxACCEL_CTRL there, this is enough to make the
accelerators work even though it's not clear whether this is really the best
thing to do or if we should use a separate "Cmd+" prefix for it (and recognize
it in Parse() too then) as otherwise it's unclear why do we have wxACCEL_CMD
at all, it just seems to be treated identically to wxACCEL_CTRL everywhere.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68463 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Replace it with wxWindowWithItems<> template class which takes care of
disambiguating between the two inherited Get/SetClientXXX() versions and use
it as a base class in all clases that previously used the macro.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68460 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use wxCONTROL_ITEMCONTAINER_CLIENTDATAOBJECT_RECAST for wxOSX/Cocoa too, not
only for wxOSX/Carbon. This macro adds methods to explicitly disambiguate
between the two inherited versions of each GetClientXXX() method, the one from
wxItemContainer and the other one from wxEvtHandler.
Closes#11637.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68459 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
We now need wxEVT_XXX constants declarations in this file (at least when not
wxHAS_NATIVE_TAB_TRAVERSAL) so include wx/event.h to fix PCH-less build of
wxOSX.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68426 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
OS X' wxComboBox::Init does not exist anymore since r68366 but an implementation still was present in combobox_osx.cpp which is used in Cocoa compilation. Removed the function.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68421 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
At least apple-gcc 4.0 and 4.2 gave a compilation error on the three Connect calls in containr.h, insisting (unless using -fpermissive) on a declaration of Connect because there are no arguments to it that depend on a template parameter. Fixed by prepending BaseWindowClass to the Connect calls. Regression since r68363.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68420 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This method did the same thing as the base wxWindow class event handler.
Also remove wxPickerBase event table which became empty after removing this
method.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68368 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
For some reason the test for AcceptsFocusFromKeyboard() wasn't done in the
correct place when constructing the GTK focus chain and even windows returning
false from it were still added to it.
Do not do this any more, this prevents the windows which are really not meant
to be focusable from keyboard (such as the pseudo-buttons in the generic
implementation of wxSearchCtrl) from gaining focus unexpectedly.
See #12808.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68367 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Simply inherit classes which need to provide TAB navigation among their
children from wxNavigationEnabled<> and remove the now unnecessary
WX_DECLARE_CONTROL_CONTAINER() macros.
Also remove WX_INIT_CONTROL_CONTAINER(), WX_DELEGATE_TO_CONTROL_CONTAINER()
and WX_EVENT_TABLE_CONTROL_CONTAINER() which are not needed neither any more.
And remove the event tables which became empty after removing the last macro.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68366 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The search control buttons don't show that they have focus and are not meant
to have it anyhow as they are more control decorations than real buttons and
their functionality can be activated by pressing "Enter" or "Escape" already
from the keyboard. But giving it to them made TAB behave unexpectedly and
wrongly when wxSearchCtrl had focus.
Override AcceptsFocusFromKeyboard() to return false to correct this.
See #12808.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68365 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Derive generic wxSearchCtrl implementation from wxNavigationEnabled<> to
ensure that TAB navigation works correctly in it. While it did work before for
search controls without wxTE_PROCESS_ENTER style (because this wasn't handled
by this control itself at all in fact), it stopped working as soon as this
style was used in wxMSW because then the navigation was implemented by
manually calling wxWindow::Navigate() and this requires wxControlContainer
support.
Use wxNavigationEnabled<> to easily add it to wxSearchCtrl.
See #12808.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68364 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Provide a clean, public and documented way to implement proper TAB navigation
for subwindows of a composite control: instead of using various ugly and never
documented WX_XXX_CONTROL_CONTAINER macros it is now enough to simply inherit
from wxNavigationEnabled<BaseClass> to do it.
No real changes in the code as the new class is not used anywhere yet.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68363 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Multiline edit control posts WM_CLOSE to its parent window when Escape key is
pressed inside it for some reason. This is unwanted as it totally bypasses our
logic for only closing the dialog when Escape is pressed if there is a
Cancel-like button in it, so suppress this behaviour by not letting the edit
control to get Escape at all.
Closes#12501.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68351 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Using PopState() without a previous PushState() is an error but it shouldn't
result in a crash, so add an assert guarding against it.
Closes#13197.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68344 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
