Oops, the command in the previous commit message should have been
sed -i'' -e '/^"Project-Id-Version/s/: wx.*/: wxWidgets 3.1\\n"/' locale/*.po~wxstd.po
but the last quote was forgotten.
Updated automatically, using the following command
sed -i'' -e '/^"Project-Id-Version/s/: wx.*/: wxWidgets 3.1\\n/' locale/*.po~wxstd.po
("~" pattern is a zsh extension).
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.
This is used by WebKit2 backend under Unix with configure, but is not needed
under the other platforms and prevented bakefile_gen from generating all
output files due to the of undefined USE_WEBVIEW_WEBKIT2 variable.
We could define it for formats other than autoconf, but this doesn't seem to
be useful currently, so just avoid referencing it instead.
Closes#17860.
No real changes, just explain the real reason why we can't create the windows
with the correct sizes and need to set them later (it's not because of the
font but because UDM_SETBUDDY changes them) and also use a helper
"effectiveSpinWidth" variable.
wxSpinCtrl created at the given position was always placed at (0, 0) instead
since 05b980aba1 ("Fix wxMSW wxSpinCtrl
appearance: show arrows inside the control").
Fix this in the minimally intrusive way for now by just putting it at the
right position instead of using hard-coded (0, 0) which was done before for
some reason.
See #12297.
Follow up to 60bd6842e4. Apply equivalent
changes to wxMarkupToAttrString, add a new wxItemMarkupToAttrString
class for mnemonics-less strings and use it in wxDataViewTextRenderer.
Also, remove the other calls to PKG_PROG_PKG_CONFIG which are then no longer
necessary.
This ensures that all PKG_CHECK_MODULES() calls work correctly and, in
particular, fixes detecting cppunit under macOS and, due to this, Travis CI
build.
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.
When using -jN, setup_h needs to be created first to avoid a bug due to
missing dependencies in the current makefiles which breaks the build
otherwise.
Use dedicated macros to declare and define IUnknown interface in the helper
class of wxNotificationMessage implementation.
Now dependency on wxUSE_OLE is more visible, since these macros are defined
in oleutils.h (see f2e707f095).
Since being able to access the 64 bit registry from 32 bit code and vice
versa (a5c468483d) the updated code in wxRegKey::DeleteKey hasn't worked
properly for keys that are redirected. It is for example not possible
from 32 bit code to delete keys from the 64 bit view of (parts of)
HKLM/SOFTWARE/ . And in 64 bit code it's not possible to delete keys
from the 32 bit view of HKLM/SOFTWARE/ which is at
HKLM/SOFTWARE/WOW6432Node/ . Fix by trying to call the correct DLL
function (RegDeleteKeyExW or RegDeleteKeyExA), instead of non-existing
RegDeleteKeyEx.
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.
Dedicated wxDataObject::SetData() function can be used to import raw
clipboard data to the corresponding instances of wxDataObject and hence
there is no need to duplicate data retrieval code.
When HBITMAP is assigned to wxBitmap with SetHBITMAP(), internal data
member representing wxBitmap's color depth should be set afterwards to
the bitmap color depth, not to the number of planes.
wxRect to draw the background was prepared in a wrong way if wxDataView had
vertical or horizontal rules.
Fix this by adjusting the correct component of the rectangle when using
horizontal rules and by fixing an off by one bug when using vertical ones.
