After the recent dynamic array macros refactoring, there was no
implementation of wxBaseArray any more and only wxArrayString-related
code remained in this file, so just move the latter to arrstr.cpp, where
it should have been put from the beginning (except that this code
probably predates arrstr.cpp addition), and remove the old file
entirely.
The system color functions depend on the current appearance, this is not automatically set to the effective appearance (that can be changed during runtime via the system preferences), added a helper class to make sure the correct version is used for retrieval.
controlBackgroundColor should be used as a background for large controls like lists etc. this corresponds to the usage of wxSYS_COLOUR_WINDOW, thanks to dkulp
Starting with macOS 10.14 Mojave, system colors can change dynamically
when the user switches between light and dark modes. Detect this by
observing the effectiveAppearance property and emit
wxSysColourChangedEvent accordingly.
See #18146.
Use templates to implement the legacy dynamic array classes as much as
possible instead of doing it in macros.
This makes the code much more maintainable and readable as well as
easier to debug.
It also allows to avoid casts between function pointers of incompatible
types, which triggered many -Wcast-function-type warnings from g++ 8.
When the height of the AUI toolbar pane is higher than the wxToolbar, the extra
area shows a glitch. This happens because the paint handler never draws on this
area. Clearing the DC of the frame with the AUI background colour fixes this.
See https://github.com/wxWidgets/wxWidgets/pull/829Closes#18138
Casts between incompatible function types seem to be unavoidable here,
as wglGetProcAddress() always returns generic PROC type, so just
suppress the warnings temporarily.
This does the same thing but avoids gcc 8 -Wclass-memaccess warning
(harmless in this case, but potentially useful elsewhere, so it seems
better to work around rather than disable it).
The comparison could never be true as wxDEFAULT is not one of
wxBORDER_XXX values and so is not included in wxBORDER_MASK and so was
useless -- and just results in -Wtautological-compare from gcc 8.
Simply remove this check, a047aff270 added
it apparently to use themed border by default for wxVListBox, but this
was done in a better way in 28319afe55.
The callback used with CreateDialogIndirect() must return INT_PTR, which
is 64 bits under Win64, not LONG, which is still 32 bits.
This fixes a gcc8 -Wcast-function-type warning and might fix a real bug
in Win64 build too.
The callback must return LRESULT, which is 64 bits under Win64, not
int, which is still 32 bits.
This fixes a gcc8 -Wcast-function-type warning and might fix a real bug
in Win64 build too.
WNDPROC and FARPROC are not the same thing in MSW and it's wrong to use
WXFARPROC as the type of different window procedures we use.
Introduce WXWNDPROC which is more clear and correct and use it instead.
Also get rid of a few casts which are not necessary any longer.
This parameter wasn't used anyhow and casting wxWndProc or m_oldWndProc
to WXFARPROC just resulted in gcc8 -Wcast-function-type warnings.
Get rid of them by not passing the window proc to this function at all.
Don't use the deprecated since Win16 (!) and doing nothing
MakeProcInstance() and fix the signature of DDECallback() which was
actually wrong in Win64 build but the problem was hidden due to the
casts done inside and outside MakeProcInstance() before.
Remove this macro and fix the signature to actually conform to the real
callback one.
This also fixes another gcc8 -Wcast-function-type warning.
Dramatically simplify dynamic array macros by keeping only the
implementation previously used in wxUSE_STD_CONTAINERS case and dropping
the other one, as we can use the std::vector-based implementation on top
of our own wxVector<>, which is available whether wxUSE_STD_CONTAINERS
is 0 or 1.
This allows to get rid of tons of ugly macro-based code without breaking
compatibility.
After bd650ec and cad2b9c, showing a popup menu in wxTextCtrl with
wxTE_RICH2 and then dismissing it without choosing a command would
result in the cursor flickering between arrow and beam cursors until
another context menu was shown.
See https://github.com/vslavik/poedit/issues/483
Fixed by checking if the popup menu is still valid (and so shown) in
the cursor handling code.
These events are unexpected and inconsistent with the other platforms,
including GTK+ 2, so make sure we don't send them during the
destruction.
Closes https://github.com/wxWidgets/wxWidgets/pull/821
The actual number of pages is given by the number of elements in
m_PageBreaks vector after CountPages() is shown and is unknown until
then, so m_NumPages is completely unnecessary and can be just removed.
Prefer the use of the standard-like template class to macro-based list.
It also makes more sense to use a vector rather than a linked list here,
as the elements are never removed from or inserted into m_Filters, so
there is no reason to prefer the list structure.
This parameter is not actually needed for any reasonable page breaking
algorithm, as it shouldn't care about any previous page breaks except
for the last one, which is already known as "*pagebreak - pageHeight" in
this function.
Removing it will allow to stop using wxArrayInt in the code using this
method and switch to an std::vector<int> instead.
This is not a backwards compatible change, but it seems that there is
very little code actually overriding this function (none could be found
in any open source repositories) and updating it should be as simple as
removing the now unneeded argument.
There is no need to look in the known page breaks array for a page break
at the position of this cell, all we care about is whether this cell is
on the current page or not: we must insert a page break if, and only if,
it is.
No real changes in behaviour, but the code is now much simpler to
understand and this change paves way for removing "known_pagebreaks"
entirely, as it was only added for the use in this function (see
f2034f1b6e from 15 years ago), which
doesn't even actually need it.
It should also make pagination code somewhat faster.
