The last digit was truncated as the code discarded the trailing "\n"
which wasn't really there, as ReadLine() helper function already removed
it, and so ended up removing the last digit of the line number,
resulting in mostly plausibly looking but completely wrong line
information in the assert dialog.
This was already done in the other functions, but not this one,
resulting in a crash if it was called for an object with null m_nowpeer
(e.g. before it's created or when it's not a real wxNonOwnedWindow
object as when it's a subobject of wxTDIChildFrame).
See #18423.
Under wxGTK, wxGauge was returning fixed values for height and width.
This meant that the gauge would not center correctly in a sizer,
particularly under GTK+ 3 where the default gauge height is just a few
pixels.
Following this change, wxGauge renders correctly on GTK+ 3 and matches
the reference widget display in the gtk3-widget-factory app.
Note, this change will also result in a slimmer widget on GTK+ 2, but
the gauge height can be forced using wxGauge::SetMinSize() on the older
toolkit.
The gauge presentation is totally theme dependent under GTK+ 3. For
example, the user can have thicker gauges by setting the following in
their ~/.config/gtk-3.0/gtk.css file:
progress, trough {
min-height: 20px;
}
Closes https://github.com/wxWidgets/wxWidgets/pull/1353
Ellipsization code was completely broken when used with the usual
control label strings containing mnemonics: it simply stripped the
mnemonics completely, losing them even if the label wasn't actually
ellipsized, and turned "&&" into a mnemonic. I.e. "&Plug && play"
appeared without underlined "P" but with underlined space before "play"
before.
Fix this by pretending that all ampersands in the string to be
ellipsized have zero width. This is not precise, as the result of
GetPartialTextExtents() for a string with the ampersands is not exactly
the same as the sum of its result for the string without the ampersands
and the width of the ampersands themselves, but it should be pretty
close and unlikely to result in any problems in practice for the
controls labels.
At the very least this fixes the completely wrong behaviour of the
controls on the "Static" page of the widgets sample, where ellipsization
is enabled by default and setting the label text with mnemonics didn't
work at all.
This resulted in wrong letter being underlined in wxGenericStaticText
when the mnemonic occurred after "&&" (i.e. an actual ampersand) in the
label.
Add unit test which passes now, but would fail before on the last check.
The names of these methods were confusing because they implied that they
were the actual implementations of the public [SG]etLabel(), while this
wasn't at all the case.
Give them then ames describing what they really do and also update the
comments to hopefully be more clear.
No real changes.
Fix bug introduced by the (relatively) recent wxJoystick rewrite: using
"!m_buttons" is wrong as it always returns 0 for any button(s) but the
first one, we need bit-wise "~m_buttons" here instead.
See https://github.com/wxWidgets/wxWidgets/pull/942
See #1142.
Combination of multiple borders looks bad, so skip drawing the left/top
borders in wxGrid{Row,Col,Corner}LabelWindow if wxGrid already has a
border around it.
Grid contents was drawn in grey colour instead of the usual active one
when it was disabled, but the row and column labels kept their default
appearance, which looked out of place.
Fix this by greying them out too. This should have been arguably done in
73145b0ed1 ~17 years ago, but better late
than never.
Don't assume that m_findIter is always valid initially, i.e. after
FindFirst() is called, as this is not the case if the memory FS is
empty, i.e. which no files had been added to it yet.
This also allows to simplify the iteration logic, as we don't need to
check m_findArgument (which, in turn, obviates the need to clear it when
we reach the end of the iteration) and can just use m_findIter directly.
Closes#18416.
Allow changing the colour of the label in the active and hover states to
make it possible to improve its contrast with the tab background in
these states.
Closes#18406.
Even though the data is supposed to be 7-bit here, we can make an effort
to decode 8-bit data if we get any as it can't be worse than just
throwing it away.
Closes https://github.com/wxWidgets/wxWidgets/pull/1336Closes#2793.
If accepting a socket connection failed, wxSocketImpl::Accept() used
close() to close the socket even under MSW, but it can be only used for
the file descriptors there and closesocket() must be used instead for
the sockets.
Add new (private) wxCloseSocket define and use it both here, to fix the
bug, and elsewhere to make the code more clear.
Closes#18407.
Make QTreeWidgetItems editable and add SelectedClicked as an edit trigger.
Simplify closing the editor as QAbstractItemView already connects to its delegate closeEditor signal.
Ensure that wxTreeItemData is deleted.
Use a QT delegate to create editor and perform custom model update.
Connect to the closeEditor signal to send out end label edit events and decide whether to accept changes.
Items using wxSYS_COLOUR_BTNFACE (light grey in the default theme) for
their background are, for some reason, drawn using the colour of active
selection (blue) even when the control doesn't have focus.
This is wrong, but there just doesn't seem to be any way to prevent this
from happening when using the native drawing logic other than not using
wxSYS_COLOUR_BTNFACE for the background (modifying any colour channel by
1 is enough to work around the issue). So to draw the item ourselves in
this case and hope that it remains indistinguishable from the native
appearance when not using the system theme.
Closes#17988.
This is important as enabling the system theme results in changes to the
native ListView control appearance that are not undone later even if the
system theme is disabled. Notably, the item rectangle width is reduced
by 2 pixels when system theme is enabled and it's not increased to its
original value even when it's disabled later, resulting in gaps between
items through which the control background shows, for example. This also
makes items drawn using our own HandleItemPaint() slightly, but
noticeably, larger than the items using standard appearance, which looks
bad.
All these problems can be avoided if we skip enabling the system theme
in the first place if EnableSystemTheme(false) had been called before
creating the control, so support doing it like this and document that
this is the preferred way of disabling the system theme use.
Closes#17404, #18296.
Having definitions of several wxPGProperty and wxPropertyGridPageState functions in wxPropertyGrid header is misleading so they should be moved to the files with their own classes definitions for the sake of clarity.
