Scale the (still hard-coded) border in pixels by the content scale factor for
the platforms where this needs to be done, i.e. not wxGTK nor wxOSX where the
underlying toolkit already does it.
Pixel values in XRC can never be correct for high resolution displays, unlike
the pixel values passed to wxWidgets API, which could be already adjusted to
account for the resolution or obtained from resolution-dependent text metrics,
so scale them by the factor appropriate for the current resolution
automatically.
Allow calling this method with either wxSize, wxPoint or just an int.
Also provide a static overload allowing to use it even when no appropriate
wxWindow is available.
Factor out this code to a reusable ParseValueInPixels() function instead of
repeating it in GetSize() and GetDimension() (and using a hack to reuse it
from GetPosition()).
No real changes, just made some error messages more precise.
The shadow width was only used by wxMotif and bezel face not used at all since
a very, very long time, so just remove these methods from the ports which still
had them (just doing nothing) and remove support of the corresponding XRC
attributes.
This function is available on OS X since 10.5, which is the minimum
supported version of wx 3.0.
Fixes Xcode 6.3 warning triggered by checking availability of a symbol
that wasn't marked as weak_import.
Don't use this flag in a vertical sizer, it doesn't make sense.
Also use wxSizerFlags instead of multiple argument Add() overload for clarity.
Closes#16953.
This improves commit dd3cb24cc0 by fixing not
only the warning about casting int to a pointer, but also the (usually more
serious but still harmless in this particular case) warnings about casting
pointers to ints and doing it via the usual union cast instead of compiler-
specific pragmas.
Typically to achieve horizontal alignment inside a horizontal sizer a spacer
needs to be inserted before the element, so explicitly say this instead of
advising to set proportion which wouldn't allow aligning the item.
This flag is more difficult to deal with than the others as it can stand for
either wxALIGN_CENTRE_VERTICAL, wxALIGN_CENTRE_HORIZONTAL or both depending on
the sizer it appears in and the other flags used. It is also trickier to give
good error messages for it as we shouldn't complain about e.g.
wxALIGN_CENTRE_VERTICAL if it doesn't appear in the XRC at all and only
wxALIGN_CENTRE does.
Check for definitely invalid combinations such as wxALIGN_CENTRE|wxEXPAND or
wxALIGN_CENTRE combined with other alignment flags in both directions and
accept everything else.
Also remember the flag names with quotes now, instead of adding the quotes
when building the error message later because the latter doesn't work when we
include additional explanation for wxALIGN_CENTRE in the flag description.
This warning appears in each buildbot build (which is wrong on its own as
libtiff configure shouldn't forcefully regenerate its output config.h every
time neither -- but currently it does) and is annoying as it distracts from
the other warnings, so suppress it even if usually we don't do it for the
warnings in 3rd party code.
Previously it only handled wxALIGN_CENTRE, also the documentation switched to
wxALIGN_CENTRE_HORIZONTAL in 72e88d8ea3 and
preceding commits.
See #16943.
Handlers for this event expect to get wxSpinEvent but wxMSW, wxGTK1 and wxQT
sent an object of base wxCommandEvent class which resulted in invalid memory
access in the handlers when using the derived class methods such as Veto().
Closes#16948.
When parsing Unicode date formats text inside single quotes should not be
escaped and instead treated as literal text. In addition two single quotes
(either inside or outside quoted text) should be interpreted as a single
quote.
Fixes#16118.
This allows to give the exact line number of the error, unlike asserts that
happen in wxSizer code which don't point exactly to the error location when
sizers are created via XRC.
It also has the advantage of allowing to detect wrong use of wxALIGN_LEFT and
wxALIGN_TOP, unlike the asserts which can't do it because the value of both of
these flags is 0.
Complain if wxEXPAND is combined with both horizontal and vertical alignment
flags, as this doesn't make sense and, moreover, the behaviour has changed
since the last commit: now wxEXPAND is ignored instead of overriding the
alignment flags if they are combined.
Allow overriding wxEXPAND effect in one of the directions by specifying
wxALIGN_{RIGHT,BOTTOM} or wxALIGN_CENTRE_{HORIZONTAL,VERTICAL} together with
it (unfortunately this doesn't work for wxALIGN_{LEFT,TOP} as their value is 0
and so their presence in flags can't be detected).
Detect using flags corresponding to the major sizer direction (which doesn't
make sense as only the proportion governs the behaviour in this direction) and
also combinations of alignment flags with wxEXPAND.
We can't check for all the invalid combinations, but at least check for
wxALIGN_CENTER_HORIZONTAL+wxALIGN_RIGHT and wxALIGN_CENTER_VERTICAL+
wxALIGN_BOTTOM which never make sense and can be detected.
A few $Id$ references remained after commit
3f66f6a5b3 or appeared in newly added files.
Remove the lines containing svn keywords except when it concerns
third-party files. In that case keep the line as-is or collapse it to the
keyword if it had been expanded to contain wx commit information (only
occurs with src/zlib/ChangeLog).
This fixes wxComboCtrl compilation with wxUSE_LONGLONG==0 as wxMilliClock_t is
always mapped to the proper base type and hence can be used even if wxLongLong
type is not defined.
See #16939.
wxMilliClock_t is always mapped to the proper base type and hence can be used even if wxLongLong type is not defined (when wxUSE_LONGLONG is disabled).
Instead of using individual string literals use globally defined constants representing wxPG variant types (wxLongLong, wxULongLong, wxArrayInt, etc.).
Allocate our own exclusive copy of the data before modifying it, otherwise
calling ClearAlpha() would clear alpha not only for the image it was called on
but also for all the other images sharing data with it.
For IMPLEMENT_GET_VALUE macro which is used to implement specialized methods (for bool and double types) define additional parameter to provide explicitly corresponding wxPG type name. With this additional parameter it is not necessary to maintain a separate list of constants containing wxPG type names only for the purposes of this macro and globally defined literals can be used instead.
