Add labels for the columns using date format and labels for the cells
using date renderer/editor explicitly to give a better idea about what's
going on here.
Also use the same rows numbers for date cells as for the column ones for
consistency.
No real changes.
See 659ab78c6d
Ensure that last wxDataViewCtrl columns is always expanded to fit the
control width and a unit test checking for the scenario in which this
wasn't the case before, but is now.
See https://github.com/wxWidgets/wxWidgets/pull/1313
This seems unnecessary as the default log handler already outputs a new
line at the end of the message anyhow and at least some messages (e.g.
debug ones in GdkPixbuf) also contain an extra new line in them, so
adding another one here resulted in having at least one and sometimes
two extra blank lines.
Don't output "*** GTK log message while running" messages for every
g_debug() call when we the debug messages themselves will not be
displayed because G_MESSAGES_DEBUG is not set or its value doesn't
include the domain used by the message.
This results in much more reasonable output from the test suite.
See #17400.
It doesn't seem worth having it when it's only used in a couple of
places in a single file, unlike GetHwnd() which is used in dozens of
places across entire wxMSW.
Select the value of the ranged number grid editor when starting to edit
it, as is done for plain text and other editors, because this makes it
more convenient to replace the old value with the new one.
Closes https://github.com/wxWidgets/wxWidgets/pull/1626
This function, using Carbon API, is not used any longer since the
changes of 5b6af7002c, so remove it and
also remove the file where it was defined as there is nothing remaining
there any longer.
See https://github.com/wxWidgets/wxWidgets/pull/1561
This variable is totally unrelated to wxExecute(), so move it to generic
"utils" file (which hadn't existed when this variable was added to
utilsexc_base.cpp back in 5815e95907.
No real changes.
Don't try running non-bundled applications in wxCocoaLaunch(): this
prevents the code handling IO redirection from being used.
Check that we have a bundle, just like wxMacaunch(), used until
5b6af7002c, used to do.
Closes#18552.
See https://github.com/wxWidgets/wxWidgets/pull/1561
Override MSWGetFocusHwnd for wxSpinCtrl to focus the right subwindow.
So the correct window will be used in wxWindowMSW::SetFocusFromKbd and
the spin controls content will be selected on TAB key.
Under MSW allow override which subwindow will be focused for composite
windows which are implemented not as a set of wxControl (i.e. using only
Windows native controls).
This is not really an option as building requires it to be 1, so don't
make it one in setup.h/configure/cmake and just hardcode it as 1 for
compatibility.
Closes#18558.
Setting invalid colour is supposed to work and reset the background to
the default one, but asserted and then crashed due to triggering another
assert while trying to repaint the window while the assert dialog was
shown, in wxX11.
Fix this in the most expedient way by just resetting the background
colour to its initial value.
A better fix would be to leave it invalid but provide an accessor
returning the default value if the background colour is not defined.
Caused by arithmetic overflow of a signed addition and subsequent
right-shift of that (now negative) value and use as an array index.
Could only realistically occur on platforms where long is 32 bits.
See #18550
Implicitly-declared 'constexpr wxDataFormat::wxDataFormat(const wxDataFormat&)'
is deprecated because 'wxDataFormat' has user-provided
'wxDataFormat& wxDataFormat::operator=(const wxDataFormat&)'.
Add option --with-dpi=[none,system,per-monitor] to configure the dpi awareness
on Windows.
Support DPI Awareness in makefile.gcc and makefile.bcc.
The default DPI awareness is set to per-monitor.
For VS solutions, the DPI aware manifest is added as additional manifest.
For makefiles, the DPI aware manifest is included via the resource file.
Set the default DPI Awareness to per-monitor.
First two paramaters of ctors of wxPGProperty and its derivates are named
'label' and 'name' so wxDirProperty ctor should conform to this convention.
Close#18547.
They prevent fuzzing from working properly as the program aborts instead
of continuing and crashing if it mishandles incorrect input, so just
remove them -- they didn't add any safety anyhow, as asserts are dormant
by default in release builds.
If the popup menu position was explicitly specified, it wasn't taken
into account correctly in wxGTK code as it always clamped it to the
primary display boundaries, even if the window showing the menu wasn't
on this monitor at all, typically resulting in the menu shown at the
left or right edge of the monitor instead of the correct position.
Fix this by using the display containing the window instead. This
requires passing the window, or rather the menu from which it can be
retrieved, to wxPopupMenuPositionCallback too, so add a helper struct to
pass both the position and the menu to it.
Closes https://github.com/wxWidgets/wxWidgets/pull/1621
We don't provide binaries for this compiler any more, just MinGW-w64.
Also mention that SJLJ exceptions propagation mechanism is only used in
32-bit builds.
Done by running misc/scripts/inc_release, manually updating version.bkl,
rebaking and rerunning autoconf.
Also a header for the next version to the change log.
This results in the toolbar being too small to show any items in it
in wxGTK and wxOSX, because the parent window size is still the default
small one and not the actual size it will be when shown, when the size
of the toolbar is first set.
And it seems completely unnecessary to do this anyhow, as toolbar is
resized by wxAuiManager in any case.
Closes#18218.
Calling wxSocket::Accept() may return an invalid socket, especially when
non-blocking, so don't close it unconditionally.
This avoids an assertion failure in MSVC CRT due to calling
closesocket() with an invalid argument.
Carbon is not supported any more and defining m_overlayWindow, which was
only used by Carbon code, resulted in "unused private variable" warning
from clang.
This should be less important now that we don't rely on CanFocus() to
determine if we should set focus to the window any longer, but it seems
to still be better to try to make it work better for hidden windows, so
at least return true from it when full keyboard access is on.
When it's off, the behaviour is the same as before, but this doesn't
affect wxTextCtrl, whose peer NSView overrides CanFocus() to always
return true.
We almost certainly need to override CanFocus() in other views, notably
wxDataViewCtrl, wxSearchCtrl, and any other controls that can have focus
even when full keyboard access is off.
See #17340.
