It was unexpected that this method could only be used for horizontal
gauges, so make it work for the vertical ones if wxCONTROL_SPECIAL flag
is specified.
Update MSW and generic implementations and the render sample to show a
vertical gauge as well.
TAB should be used for navigation by default and only should be inserted
into the control as a literal character if wxTE_PROCESS_TAB is specified
for consistency with wxMSW and because this behaviour is much more
useful by default.
Fix this by calling gtk_text_view_set_accepts_tab() as appropriate for
multiline text controls. For single line ones, the behaviour is
unchanged but it's more reasonable as TAB is always handled as if
wxTE_PROCESS_TAB were not specified and it doesn't seem really useful to
try to support wxTE_PROCESS_TAB for them anyhow, so just document this
limitation.
Also remove the outdated/misleading documentation of this style, notably
don't say that it is required to get char events for TAB presses as
these events are generated both with and without this style in both
wxGTK and wxMSW.
Closes https://github.com/wxWidgets/wxWidgets/pull/704
The old wxEVT_SEARCHCTRL_{SEARCH,CANCEL}_BTN event names were unwieldy
and misleading because both of these events can be generated without
using the buttons, but by pressing Enter or Esc (the latter currently
works under macOS only, but this could change in the future).
Make it possible to bind to just wxEVT_SEARCHCTRL_SEARCH_BTN under all
platforms: previously, it was also necessary to bind to wxEVT_TEXT_ENTER
when using the generic implementation, as pressing Enter in the text
control didn't generate the dedicated SEARCH event.
It does now, and, to avoid any confusion, the control does not generate
wxEVT_TEXT_ENTER events at all any more. This is not really
incompatible, as wxOSX never generated these events anyhow and the
generic version only did for a couple of days, since the changes of
9816970797 which were, finally, misguided
and so are undone by this commit.
Closes#17911.
The underlying Windows TaskDialog supports adding an additional footer
to the message dialog. This makes the native functionality available
and implements it in the generic version.
See https://github.com/wxWidgets/wxWidgets/pull/573
Trying to be smart by setting m_isEnabled to false in
wxStaticBox::Enable() without actually disabling the box itself (because
it can't be done if its label window is to remain enabled) didn't really
work. For example, it was impossible to TAB to a checkbox label of the
box when it was disabled, because keyboard navigation (correctly)
doesn't recurse into disabled windows and there could be similar
problems with any other code iterating over windows and skipping over
the disabled ones.
So, finally, simplify things and keep m_isEnabled in sync with the real
box state, even if this, counter-intuitively, means that IsEnabled() on
the box returns true after calling Enable(false) on it.
This also reverts 4ee35cf5ee569b6ee6c7d0d5702484d4d2a20f96 ("Don't
disable wxStaticBox children at wx level when disabling it") as we can't
avoid really disabling the children any more now that their parent is
not disabled: without this, their IsEnabled() would return true, i.e.
they wouldn't be disabled at all, from the program point of view. This
is unfortunate for the reasons that originally motivated that commit,
i.e. if some wxStaticBox child is disabled, disabling and re-enabling
the box will now re-enable this child, even if it shouldn't, but seems
impossible to avoid. The only possible alternative is to modify
IsEnabled() to add some wxStaticBox-specific hook to it, e.g. instead of
calling GetParent()->IsEnabled() there, we could call some now
AreChildrenEnable() method, which would delegate to IsEnabled() by
default but overridden in wxStaticBox. However this seems complicated,
and will add an extra virtual function call to all (frequently
happening) IsEnabled() calls.
Allow overriding the method called when the validator is associated with
the window, this can be convenient to perform some initialization on the
validator instance actually used as it can't be done on the initially
created object itself because it will be cloned by SetValidator(),
creating a new instance.
Also change SetWindow() to take wxWindow instead of wxWindowBase, this
still requires the cast in wxWindow::SetValidator(), but it's better to
have it there rather than in wxValidator and use the simpler type in the
public function signature.
This behaviour might be not completely intuitive, but it makes it much
simpler to handle the box state using a checkbox as the label control
(which is by far the most common case of using box window labels).
Notice that while we could add a separate EnableWithoutLabel() method to
wxStaticBox to make it possible to set the state of the box directly
relatively easily, it wouldn't help with using wxEVT_UPDATE_UI for
managing the box state indirectly as it relies on calling Enable() only.
And this solution does allow wxEVT_UPDATE_UI handlers for the box itself
to work (provided the handler takes care to check for the event object
being the box itself, as otherwise it would still disable the child
checkbox when its wxEVT_UPDATE_UI bubbles up to the box).
Don't pretend that AddData() allows to add multiple objects to the
clipboard because it doesn't work like this by default under any
platform and only MSW possibly supports this in the non-default build
with wxUSE_OLE==0 -- but mentioning it in the documentation would
arguably be more confusing than helpful.
See #17925.
This reverts commit 41f6f17d01 ("return 0
(meaning the file is not seekable, as the docs now explain) instead of
4KB for the files in sysfs under Linux") as it seems to be wrong to
return a value different from what "ls -l" or "stat" return here and the
original problem was solved in a better way in the previous commit.
See #9965.
Closes#17818.
Calling this function with an unseekable file, such as any file under
/sys on Linux systems, would previously just hang as the loop condition
was never satisfied when length was -1.
Fix this by checking for this case and using a different approach by
extending the buffer we read the data into as we go instead of
preallocating it all at once.
See #9965.
Trying to give all the remaining space after allocating enough to the
other columns to the first one doesn't work well with wxDataViewCtrl,
which tries to do the same thing, but with the last column, so we
actually get some strange mix of behaviours, with both the first and
last columns changing size after the control itself is resized.
Stop fighting with wxDataViewCtrl and just let it to its own thing.
Closes#17476.
Fix a copy-and-pasto in the header and also mention that wxURLDataObject
derives from wxDataObjectComposite, and not wxTextDataObject, in wxGTK
too.
Also add a note about the exact base class being an implementation
detail.
Closes https://github.com/wxWidgets/wxWidgets/pull/624
wxDateTime timezone-related methods always use the current timezone
offset, while other methods, using CRT, use correct value for the given
date, which may be different.
This discrepancy accounted for test failures in Europe/Minsk time zone
as Belarus has switched from UTC+2 to UTC+3 since 1999 date used in the
test.
It is impossible to really fix the problem easily, so just skip the test
in this case and also mention this bug in the documentation.
See #15370.
Don't rely on time zone offset to check whether it is local as this
doesn't, and can't, work for the local time zone in Great Britain which
uses the same offset as UTC, but does use DST, unlike the latter.
Add a unit test (albeit disabled by default) checking that the code that
previously didn't work correctly in BST does work now (run the tests
using "TZ=Europe/London ./test wxDateTime-BST-bugs" under Unix to test).
Closes#14317, #17220.
See #10445.
