Refactor common code and also for upcoming accessibility from
wxCocoaOutlineView.
Part of #19003.
Co-Authored-By: Dimitri Schoolwerth <dimitri@schoolwerth.com>
This provides the same information as wxGetCpuArchitectureName(), but is
consistent with the other wxPlatformInfo accessors, which also
correspond to the existing wxGetXXX() functions, and makes it more
convenient to use this information in the application code as now
everything is available via wxPlatformInfo instead of having to use
different functions for different pieces.
We need to adjust the indices of the currently selected items as we need
to keep the same items, not the same indices, selected after new items
insertion.
Closes#18902.
Update the width when items are expanded and collapsed and also take the
expander width into account.
Change m_ModelNotifier type to avoid casts when calling wxOSX-specific
method on it.
Closes#14939.
Co-Authored-By: Vadim Zeitlin <vadim@wxwidgets.org>
This convenient method allows to expand all children of the item
recursively.
This is directly supported by both native implementations, so it makes
sense to have this in wxDataViewCtrl itself, even if it could be also
(less efficiently) implemented in the user code.
This code doesn't work (and probably doesn't compile) anyhow, but at
least try to do the right thing in it and override DoExpand() instead of
adding a virtual Expand() hiding the non-virtual version in the base
class.
This is not ideal, as resetting the page contents loses the current
selection and redoes a lot of work that could be avoided, but it's
(much) better than nothing, as it fixes the window appearance after e.g.
moving it to another monitor.
Closes#18564.
This used to work previously but got broken when using C++17 by
c3810da549 (Allow using noexcept methods with event tables macros,
2020-04-09), as cast added to deal with noexcept handlers relied on
argument type deduction which can't be done for overloaded functions.
Fix this by extracting the event argument type from the function pointer
type and specifying it explicitly, while still letting the compiler
deduce the class.
Add a test case checking that using overloaded event handlers compiles.
See #18721.
Closes#18896.
In the context of wxPlatformInfo, 'architecture' means either '32 bit' or
'64 bit'. Anywhere outside the context of wxPlatformInfo, this concept is
known as 'bitness'.
For the rest of the world, 'architecture' generally refers to the CPU
instruction set architecture, i.e. something like x86, x86_64, arm64, whereas
'operating system architecture' refers to the design of separating kernel
space, user space, etc.
Make sure these headers can be compiled even when the control they're
written for is not available in the build. Including them in this case
doesn't make much sense, of course, but not giving any errors is still
nicer and consistent with the rest of wx headers.
Replace the overloads added in c2e5f3520a (Add a wxRound() overload for
int, 2020-11-05) and 1cf7c47934 (Add more wxRound() compatibility
overloads and improve docs, 2020-11-05) with a template function that
should work for all integer types.
This fixes compilation of existing code using wxRound() with size_t
values: while this doesn't make any sense, it doesn't make much less
sense than using it with int, so let people avoid having to change their
code when upgrading to wx 3.2.
Also add at least some minimal tests for this function.
Closes https://github.com/wxWidgets/wxWidgets/pull/2119
This requires refactoring NewCloseButton() in order to extract
CreateCloseButton() from it, as XRC relies on being able to use two-step
creation which was previously impossible for this kind of buttons.
CreateCloseButton() is rather unusual, as it has to be declared in the
derived, platform-specific class, in order to be able to call its
Create(), but is defined only once in common, platform-independent,
code. However the only alternative seems to be to have a static
function, e.g. InitCloseButton(), which wouldn't be very pretty neither.
Closes https://github.com/wxWidgets/wxWidgets/pull/2118
IsEnabled() wrongly returned true even when the TLW was actually
disabled due to a native modal dialog using it as owner being currently
shown.
Fix this by trusting the actual HWND state, rather than our internal
m_isEnabled, except before the window is created.
Do it for TLWs only even if, in principle, we could check for
WS_DISABLED for the other windows too. However this would make
IsThisEnabled() inconsistent with the other platforms, where it returns
true when the window parent is disabled, but the window itself isn't,
which is currently also emulated by wxMSW, but wouldn't be the case if
we trusted WS_DISABLED presence. And while there might be other problems
due to lying about the actual window state in this function, it doesn't
seem to create any problems in practice, so for now leave the old logic
in place.
As a side effect, this makes wxWindowDisabler work correctly when a
message box is shown by another window when it's created, as it will now
correctly avoid re-enabling the message box parent in its dtor.
Closes https://github.com/wxWidgets/wxWidgets/pull/2117
See #11887.
No real changes, just get rid of an unnecessary instance of
wxWindowList: this one can be safely replaced with a vector because it's
a private member and so changing its type doesn't affect compatibility.
No real changes, just remove asserts verifying that a pointer is
non-null right before dereferencing it, as they're perfectly useless for
all the usual reasons and just add extra code to relatively often used
functions.
This is very similar to 8a64b6acea (Fix inheritance hierarchy of
wxTimePickerCtrlGeneric, 2020-11-04) and is done for the same reasons
(avoid having to somehow implement MSW-specific virtual methods of the
native controls base class in the generic version) and suffers from the
same drawback (there is no common base class for the native and generic
version any more).
See https://github.com/wxWidgets/wxWidgets/pull/2109
This is more consistent and slightly simpler.
Testing for _tsystem() explicitly is not needed any more as _wsystem()
is supported since MinGW 3.4.5, i.e. certainly present in all supported
MinGW versions.
See #18958.
Replace SetListRulesAlternateColourOnBlank() taking 2 arguments, with
the second of them being used only when the first one is true, with a
simpler but still sufficient ExtendRulesAndAlternateColour(bool).
Make the new method virtual and define it as doing nothing in
wxListCtrlBase class, so that it's still available, even if currently
not implemented, in wxMSW.
Also simplify the implementation, fix style problems and other minor
improvements.
Previously they were both limited to the part occupied by the items
only, add a new method allowing to extend them to the whole client
window area.
See https://github.com/wxWidgets/wxWidgets/pull/2106
Make the overloads added for compatibility available only when
WXWIN_COMPATIBILITY_3_0 is on and add two more of them, to cover all the
interer types (except char but, honestly, who rounds those?).
Also improve the documentation and make it clear that this function is
not needed at all in the new code.
Closes https://github.com/wxWidgets/wxWidgets/pull/2111
Check if edge webview runtime is available in the call to
wxWebView::IsBackendAvailable() instead of only doing it during
process initialization. This allows an application to install
the Edge WebView2 Runtime during runtime and use the edge webview
afterwards without restarting the process.
Tell the SDK controller if the control is shown or hidden.
This allows creating a hidden webview which will be shown later
and might fix other potential issues.
Setting EnableContextMenu and EnableAccessToDevTools where
ignored before the webview loaded content. This would often
be set directly after creation and work like this with other
backends.
This allows to customize the string shown when there is no valid date
under MSW (only, for now) and can be notably used to suppress the
unused date completely, which can be useful to lighten up the display
when there are many controls.
Add UI elements to the widgets sample allowing to test the new function.
This class must not derive from the native wxDatePickerCtrl, as it
doesn't make much sense and resulted in the need for an ugly hack with
either overriding unused and inapplicable pure virtual methods in this
class itself, as was originally done in 569c7d8ccb (Add wxTimePickerCtrl
class., 2011-09-29) when it was introduced, or not making these methods
pure virtual in the first place, as was done in d0da5061ce (Dirty hack
to allow generic wxDatePickerCtrl to compile under MSW., 2011-10-20),
but didn't really fix the problem.
Do fix it now by using different hierarchies for the native and generic
classes. The main disadvantage of doing it is that there is no common
base class for wxTimePickerCtrl and wxTimePickerCtrlGeneric providing
SetTime() and GetTime() methods any more, but this seems like a
relatively small price to pay because real applications won't be using
these two classes simultaneously, as the calendar sample does, anyhow.
Unlike wxGridCellDateRenderer, which already did it, the editor class
always got the cell value from the table as a string, even if the table
supported returning the dates directly.
Fix this by using the same code in the editor as in the renderer, which
required a further refactoring in order to make it reusable: the helper
TryParseDate() was replaced with TryGetValueAsDate() and DateParseParams
was added to allow overriding the arguments passed to it in the
overridden wxGridCellDateTimeRenderer::GetDateParseParams().
This is needed to allow editing the cells using wxGridCellDateRenderer
with a custom format, otherwise the editor might parse the contents of
the cell differently from what is actually shown.
In particular, this ensures that using "date:%d.%m.%y" (or any other
custom format) as "cell type" works correctly, which wasn't the case
before.
