Xcode project: src/regex must be in non-user search path

Otherwise it wouldn't be included as <regex.h> and the system copy would
be used. We need to always use the builtin, wxChar-aware copy.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78216 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Remove unneeded CacheBestSize() from wxMSW wxDateTimePickerCtrl.

The best size is already cached by the base class GetBestSize(), no need to do
it here as well.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78219 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Add wxLocale::GetOSInfo() and use it in MSW wxDateTimePickerCtrl.

This fixes the size of wxDateTimePickerCtrl in programs that don't set any
specific locale: previously, the standard "%m/%d/%y" format was used for
computing the best size of the control in this case, but this could have been
significantly shorter than the format actually used (compare with the default
"%d %b, %Y"), resulting in the control contents being truncated by default.

GetOSInfo() is currently different from GetInfo() only under MSW, but we might
need to make the same distinction under OS X too, so do make this function
public instead of keeping it MSW-specific.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78220 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use DTM_GETIDEALSIZE to implement wxDateTimePickerCtrl::DoGetBestSize().

If possible, i.e. when running under Vista or later, just ask the control for
its best size instead of trying to approximate it ourselves.

Notice that we still use our own height, to ensure that it's the same as for
the text controls, but it's the width that really counts.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78221 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Send idle events from inside wxYield() in all ports, including wxMSW.

This means it can be now done in wxEventLoopBase itself and calls to
ProcessIdle() in the port-specific code are not needed any more, so remove
them.

This introduces a change in behaviour for wxMSW, where idle event handlers
were not invoked from inside wxYield() at all previously, and for wxOSX, where
only a single idle event is now generated from wxYield() instead of a stream
of them until no idle handler needs any more of them as before. But on the
bright side, the new behaviour seems to make most sense and is now the same in
all ports.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78222 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Document the long existing wxFrame::DoGiveHelp().

This function was added way back in 2002 (r15339) but was never documented.
Do it now as it's a useful method to override for customizing the help strings
display.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78223 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
No real changes, just shorten log messages in the MDI sample.

There is not enough space for the relatively long messages logged when menus
are opened or closed (added in r78130), shorten them as much as possible while
leaving them still readable.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78224 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Add logging of wxEVT_MENU_HIGHLIGHT events to the MDI sample too.

This allows to easily compare which events are generated and sent to which
objects under different platforms.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78225 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Add a popup menu to the MDI sample.

This is just to test how wxEVT_MENU_HIGHLIGHT events from popup menu items are
handled under the different platforms.

Also log menu events to the canvas window too as it now gets some.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78226 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Remove "isPopup" parameter from DoSendMenuOpenCloseEvent() in wxMSW.

This parameter is redundant, we can find out whether a menu is a popup one or
not from the menu itself, assuming that we always have a valid wxMenu pointer
for popup menus events, which really should be the case (we may not have one
for the events from system menus).

This allows to handle popup menu events case in the base class version of
MSWFindMenuFromHMENU() which will allow to reuse it from places other than
DoSendMenuOpenCloseEvent() without code duplication now.

There should be no changes to the behaviour, this is just a simplification.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78227 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Refactor: extract menu event handling logic from wxMenu::SendEvent().

Make this logic available for reuse with the events of different kind, e.g.
wxMenuEvent in the upcoming commit.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78228 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Fix fields initialization in wxCommandEvent copy ctor.

Neither m_isCommandEvent nor, worse, m_propagationLevel was set correctly for
wxCommandEvent objects constructed using copy ctor -- and hence Clone(). This
means that such events were not propagated upwards the window hierarchy, quite
possibly resulting in mysterious bugs.

Fix this now by initializing these fields in both the normal and copy ctors.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78229 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Harmonize wxMenuEvent handling between all major ports.

Send these events to the menu itself first, then to the menu bar containing
it or the window invoking it if it's a popup menu and, finally, to the top
level window in all of wxGTK, wxMSW and wxOSX.

In particular, this ensures that help strings are now shown in the parent MDI
frame status bar by default, even when the menus are attached to the client
MDI frame or shown as popup menus.

At the implementation level, this logic is now encapsulated in a new static
wxMenu::ProcessMenuEvent() method which can be easily modified and reused in
other ports.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78230 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Remove unnecessary assert from wxMenuBar::MSWGetMenu().

This assert was triggered after the changes of the previous commit as we can
get WM_MENUSELECT with menu bar handle as parameter from Windows and still
search for the menu with this handle -- and there is nothing wrong with this,
so just return NULL but without asserting in this case.

This corrects the changes of r67355, see #13080.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78231 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Don't put wxMenu::MSWGetMenu() inside wxUSE_OWNER_DRAWN check.

This doesn't make any sense, this function is not related to the owner drawing
code at all and should always be available.

This corrects the changes of r70316, see #13851.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78232 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Fix crash when using wxMessageBox before creating wxTheApp.

CheckIfCanBeUsedAsParent() used by wxMessageBox ctor shouldn't dereference
wxTheApp unconditionally, otherwise it's impossible to show a message box
before creating the application object or after destroying it without crashing.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78233 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Don't dereference wxTheApp unconditionally when showing wxMessageDialog.

The application might not yet (or already) exist, don't crash in this case.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78234 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use the layout direction of wxTextCtrl itself, not the app, in wxMSW.

A wxTextCtrl inside an RTL window in an otherwise LTR application should still
be considered RTL, it's not clear at all why do we need to ask the application
for the layout here, so change this for consistency.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78235 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Fall back to default process layout direction in wxMSW.

Add helper wxApp::MSWGetDefaultLayout() static method and use it instead of
wxTheApp->GetLayoutDirection() in wxMSW code.

This serves two purposes: first, wxMessageDialog doesn't crash when it's shown
before wxTheApp is created (or after it's destroyed) any more. And second, we
use the correct layout direction if the main application has enabled it by
calling SetProcessDefaultLayout() or using two U+200E characters in the
beginning of its "FileDescription" resource field by default now.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78236 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Don't use right-to-left markers in wxMSW wxMessageDialog code.

This mechanism is provided as an alternative to specifying MB_RTLREADING
style, e.g. if the source code can't be modified but the [string] resource
from which the message box message is loaded can be. We don't need to do this
if we do add MB_RTLREADING however.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78237 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775