Don't call wxSetlocale() in DoInit() any more, this was redundant when
it was called from Init(wxLanguage) overload.
Add new DoCommonPostInit() called from both Init() overloads after
setting the locale in whichever way they do it to avoid code
duplication.
As a side effect of this change, the error message given if the locale
can't be set is the same now independently of the ctor/Init() overload
used (previously it differed depending on whether a wxLanguage or the
name of the language as string was passed) and it's always logged using
wxLogWarning() and not it in one case and wxLogError() in the other one.
Instead of calling wxLanguageInfo::GetLocaleName(), which called
setlocale() at least thrice (first to query the current locale, second
to try to change it and third to restore the original locale) and then
calling setlocale() again if it succeeded, use the new TrySetLocale()
method which calls setlocale() just once and doesn't require calling it
again in the caller.
This makes the code slightly more efficient but, more importantly,
shorter and more clear.
Re-enable alignment support for wxDataViewCtrl cells in wxOSX which was
previously disabled just to allow the library to compile in 32 bits.
Closes https://github.com/wxWidgets/wxWidgets/pull/377
Define wxCLRDLGG_USE_PREVIEW_WITH_ALPHA as either 0 or 1 instead of using an
expression involving "defined" for it as the latter provoked many clang
-Wexpansion-to-defined warnings, which were harmless but very annoying.
Use underscores on them to show that they are different from properties or
local variables (in pure Objective C they would actually start with
underscores, but this is not a good idea in C++ code) and avoid conflict
between a member name and "wxAlignment" type name, which was confusing.
Instead of disabling vertical alignment support in wxDataViewCtrl, move the
private variables to the header file: this is supported by all versions of the
Objective-C runtime, including the old one used for 32 bit applications,
unlike the new way based on declaring the variable in an anonymous extension.
This replaces the changes of 22216b70e7.
Ensure that the restored size is at least equal to the best size of the
window to avoid cutting off parts of it in (a common) case when a newer
version of the program adds new UI elements, thus increasing the window
best size and possibly making the previously stored size too small.
A simulation of context menu event by handling directly EVT_RIGHT_UP was implemented in wxSTC in 451c5cc7b9, but later on, EVT_CONTEXT_MENU generation in wxOSX was fixed in 524c47aa3a so simulation is no longer necessary and this event can be directly handled in wxSTC.
In order to allow inclusion of configure determined flags via a wx/setup.h include also for xcode builds, the include has to move into the setup0.h template
Don't do it at all in the ctor, initializing just the first element of
the array is useless as it's overwritten by EncodeChar() anyhow, so just
leave the task of NUL-terminating the data to this function as well.
It might be even better to just have a ctor taking wxUniChar in these
classes instead and make EncodeChar() a trivial wrapper around it, but
for now just apply the minimal fix to repair the test breakage after the
last commit.
See https://github.com/wxWidgets/wxWidgets/pull/467#issuecomment-310384946
Don't rely on default array initialization, not only it may not work
with some really old compilers (which is actually not that important as
we don't seem to rely on these arrays being initialized, in fact), but
it results in warnings about working correctly (sic) from MSVC in
versions from 9 up to 12 inclusive.
See https://github.com/wxWidgets/wxWidgets/pull/467#issuecomment-310193867
Rename relatively new enum value wxTASKBAR_JUMP_LIST_DESTIONATION to
wxTASKBAR_JUMP_LIST_DESTINATION as well as a private function containing
the same typo.
This should always the case now, but wasn't when not using configure
(e.g. in MSVC builds) before, so verify this explicitly to ensure that
we don't just silently define wxUSE_UNICODE_UTF16 wrongly, as it
happened before the fix in the previous commit.
* using fontAttributes dictionary allows for better emulation of bold typefaces, also switch to using color from context, this allows keeping the same dict throughout, as a side effect fix font caching
* reverting in order to maintain crossplatform compatibility
* applying review suggestions
* applying review suggestions
* wxGetClipboardData was removed through commit
b375d81499 "Use wxDataObject methods..."
but former usages will break with unreferenced
function as the header still advertises the function
Change-Id: I77e756d2b7d0db7c3833578d2846f4e922a55262
* Add 'wxTextFileType m_fileType' to hold the type
* Add 'wxString m_eol' to hold the end of lines string
* Add SetFileType() and GetFileType() to set and get the type
* Add GetEOL() to get the end of lines wxString
* Backwards compatibility preserved by using wxTextFileType_Unix
Change-Id: I3e8547b377e2c4060a3a2d97c299a08ea2c0a376
Signed-off-by: Adrian DC <radian.dc@gmail.com>
GetPrintDC() should return a new device context created by the print
dialog, not the duplicate of existing context passed from the caller
(e.g. from wxGtkPrinter) through SetPrintDC(). Therefore SetPrintDC() is
no longer useful and can be removed.
Move it out from the auto-generated section to avoid losing it during the next
build/update-setup-h execution (see e24bc249e4
which added this option in the wrong place).
