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).
Generic implementation from wxDCImpl doesn't work well with wxPrinterDC
under wxGTK.
(This implementation is adopted from wxCairoContext::GetPartialTextExtents.)
Replace an accidental comma with the semicolon, which is what should have been
used here since the beginning (even though comma actually did do the same
thing).
This was erroneously removed by e82c619402 but
it still needs to be defined here, even if it's not used under macOS, in order
to avoid errors about it being undefined in wx/unix/chkconf.h.
UpdateStyle() function was introduced in edccf428 to synchronize in
SetWindowStyleFlag() style of the control with new style flags just stored
in m_windowStyle.
In 9a8d75f1, storing directly a new flags in m_windowStyle was replaced by
the call to parent's SetWindowStyleFlag().
Because call to parent's SetWindowStyleFlag() updates both m_windowStyle
and actual style of the control for common flags (WS_*, LVS_* flags),
synchronizing the control again with UpdateStyles() is pointless (since
this function does nothing in this context).
Only wxSCROLL style flags need special care because wxListCtrl doesn't
have these styles but the control itself may have them. In order
to preserve them in the call to SetWindowStyleFlag(), we can do the trick
and request the same new scroll style as the actual physical style.
UpdateStyles() is useless now and can be deprecated.
See #17059.
Follow up to 60bd6842e4. Apply equivalent
changes to wxMarkupToAttrString, add a new wxItemMarkupToAttrString
class for mnemonics-less strings and use it in wxDataViewTextRenderer.
IUnknown interface is used sometimes (e.g. in WinRT implementation of
wxNotificationMessage) alone, without other OLE routines, so it is
helpful to have its code in the separate file to avoid coupling with main
OLE code when only IUnknown implementation is required.
WinRT implementation of wxNotificationMessage requires wxUSE_OLE because
one memeber variable is of type wxAutoULong which is defined in the OLE
utilities collection (oleutils.h).
Library itself can be built successfully when wxUSE_DRAG_AND_DROP==1 and
wxUSE_OLE==0 but several wxDropTarget functions (referred in wxWindowMSW,
wxTextDropTarget, wxFileDropTarget) are reported as missing during linking
the application.
Reorganize the code by putting OLE-dependent code into the blocks
controlled by wxUSE_OLE and by sharing remaining code (like implementation
of wxDataFormat, wxBitmapDataObject, wxFileDataObject, etc.) to allow
building wxDataObject and its specializations also without OLE support.
Since wxDataObject no longer requires OLE support, corresponding check in
checkconf.h can be removed.
Thanks to this additional flexibility, it is possible to use wxClipboard
whether OLE support (wxUSE_OLE) is enabled or not, either with OLE-based
wxDataObject (OLE clipboard) or with wxDataObject decoupled from OLE (Win
clipboard API).
wxMetafileDataObject is a specialization of wxDataObject and its
compilation should be controlled directly by wxUSE_DATAOBJ (like it's done
under wxOSX, see e.g. include/wx/osx/metafile.h), not by
wxUSE_DRAG_AND_DROP.
Some wxWindowBase functions were marked deprecated prior to wx 3.0 release
and therefore they should be inserted into WXWIN_COMPATIBILITY_2_8 blocks
to mark them for removal in a future wx version.
Order array cannot be extended both in DoInsertItems() and DoInsertOneItem()
functions because DoInsertOneItem() is invoked indirectly from DoInsertItems()
(through the call to wxCheckListBox::DoInsertItems() and DoInsertItemsInLoop())
and therefore order array would be eventually extended by two items for one
inserted list item. To avoid this duplicated actions, we should resign from
overriding DoInsertOneItem().
In wxRearrangeList implementations (like wxMSW) where DoInsertItemsInLoop()
and DoInsertOneItem() are not used to insert multiple items, DoInsertItems()
has to be overriden to do this insertion.
See #17836.
Number of indices stored in the internal order array has to be the same as
number of the items, so whenever item is added or removed, order array
has to be adjusted accordingly.
Closes#17836.
This method doesn't override any virtual method in the base class, so
wxOVERRIDE can't be used here.
In fact, this method doesn't seem to be used at all, but keep it for
compatibility and in case we want to use it later, as wxGTK does.
No real changes, just use DST_OFFSET constant instead of 3600 and remove the
"FIXME" comments as we're not actually going to fix anything here but will
just continue to assume 1 hour shift for DST.
Since the changes of c9a458bfe8 ("Use Win32
::CommandLineToArgvW() to tokenize command line"), this is not guaranteed any
more as this Win32 function doesn't necessarily ensure it under older MSW
versions such as XP.
Just use "argc" explicitly instead of relying on this in wxCmdLineArgsArray to
fix crashing under XP.
Handle "&" in exactly the same way as "&" in wxMarkupParser, i.e. do not
map the former to "&&" to prevent it from being interpreted as a mnemonic as
this is incompatible with using markup for anything but the control labels,
e.g. for wxDataViewCtrl items text, in which mnemonics are not recognized.
And even when using markup for control labels, it was a questionable decision
as it's really not clear at all why should the XML entity and the raw
character itself be handled differently.
Also split wxMarkupText into two classes, wxMarkupText that handles
mnemonics in the markup (which is typically a label) and a very
similar, but not derived, wxItemMarkupText that handles mnemonics-less
markup for list etc. items, uses DrawItemText() and supports
ellipsizing.
Illustrate the use of ampersands in the dataview sample.
This method is only used, and defined, when using rich edit controls, so don't
declare it if wxUSE_RICHEDIT==0.
This should fix a link error in this build variant.
Closes https://github.com/wxWidgets/wxWidgets/pull/452
Assert and return false instead, this is more developer-friendly.
Add unit tests to check that these functions really work as expected when
called on a closed file.
Closes#17828.
This makes sense and avoids an error if some other header sabotages our
__has_warning definition check by providing a dummy definition for it (as ICU
does, for whatever reason).
