This allows to show message boxes in ports other than wxMSW too by doing
it only when it is safe, i.e. when the GUI is initialized, while still
keeping the old code directly using the native MessageBox() function for
MSW for maximal robustness.
Although we don't want to use MB_TASKMODAL unconditionally, because it
results in non-optimal UI behaviour when there is a parent window, there
is no reason not to use it when we don't have any parent anyhow, so do
this, at least.
Pass correct parent HWND to ::MessageBox() in order to disable the
window while the message box is shown, as this function is supposed to
be similar to modal wxMessageBox() and it was unexpected that the
application could be reentered via the event handlers from inside it.
This required adding wxAppTraits::GetMainHWND() in order to only use the
HWND in GUI applications from the function defined in non-GUI code.
This trivial function just allows to avoid checking if wxTheApp is not
null before calling GetTopWindow() on it.
Replace the existing "wxTheApp && wxTheApp->GetTopWindow()" calls with
wxApp::GetMainTopWindow().
No real changes.
This internal function will be useful to check if the modules are
already initialized, i.e. if the library is in the "steady state"
between the end of the initialization and the beginning of the cleanup
phases.
Simply use wxVector instead, this shouldn't be less efficient (we rarely
remove the modules from the list and iterating over a vector should
actually be faster, as well as consuming less memory), but it avoids
ugly macros, is simpler to use and to debug and will be trivial to
replace with std::vector<> in the future.
No real changes, this is just pure cleanup.
For generic wx{Dir|File}PickerCtrl with text field the picker button
should be as high as the associated text field also when
wx{FLP|DIRP}_SMALL flag is set.
Closes#19087.
Avoid the need for ugly WX_NO_LOCALE_SUPPORT macro at the cost of a
couple of extra #ifs, which seems to be a worthy trade-off.
This also allows making the code calling setlocale("") for the default
language platform-independent.
No real changes.
Even if we do know about the system language, it's still better to let
OS/CRT handle it, as we may not know enough about it. E.g. "system
language" may actually be a mix of the different languages and formats
and we don't handle this case at all, while OS/CRT do just fine.
We must use GetUserDefaultUILanguage() and not GetUserDefaultLCID().
Although still not ideal, this is much better when the UI language and
the locale differ: when everything is in some language, it's better to
use this language and wrong date/number format than use correct
date/number format but a wrong language.
See #11594.
Check if the path is at least two characters long before accessing its
second character.
Add test cases for wxIsAbsolutePath() on MS Windows.
Closes https://github.com/wxWidgets/wxWidgets/pull/2262
Don't return unconditionally before another return. Somehow gcc doesn't
warn about it, but other compilers (and static analyzer tools)
definitely do.
No real changes.
If we can't find an exact match for the system locale in the database,
try to at least find the corresponding language.
This is almost certainly what the intention of the original code was, as
otherwise the entire loop was useless because it couldn't find anything
that wouldn't have been found in the loop just above.
This allows to correctly load German translations when using unsupported
locale such as "de_IT", for example.
See #19082.
wxGetKeyStateGTK() is intended to be used only with non-X11 GTK backends.
wxGetKeyStateX11() should still be used on GTK3 w/ X11 as the GTK
variant does not provide all key states.
Define the function calling setlocale("xx_YY") first and then just
setlocale("xx") if the former failed, instead of doing the same thing
manually in 3 different places.
Also avoid attempting the second setlocale() call completely if there is
no "_YY" part in the first place.
No real changes.
Call the info->CanonicalName "shortName", as it's done in many other
places in the code instead of using "locale" for it here, even though we
do use it as a name of locale.
No real changes.
