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).
