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
