This reverts changes to one of the arrays in 39706e4db0 (Use wxBaseArray
instead of object arrays in wxAuiManager, 2023-04-11) as this array is
returned by wxAuiManager::GetPane() and the existing code relies on the
references to the elements of this array remaining stable even if the
array is modified, which would be impossible with an array storing the
objects directly, so return to storing heap-allocated pointers to it.
There should be no such problems with the other arrays changed by that
commit, so leave them unchanged.
Closes#23545.
The wxThreadSpecificInfo object created by wxThreadSpecificInfo::Get()
was only released by the wxThreadInternal's cleanup, which meant that it
was leaked if wxThreadSpecificInfo::Get() was called by a thread not
created by wxThread, e.g. when using std::async or std::thread.
Fix this by simply using C++11 thread_local and removing the entire
wxThreadSpecificInfo machinery entirely.
See #23535.
Closes#23543.
Set LIS_DEFAULTCOLORS to allow the already existing code calling
SetForegroundColour() in wxGenericHyperlinkCtrl to work.
Changing the foreground colour has an unfortunate side effect of also
changing the colour of the focus rectangle, but it doesn't seem possible
to avoid this.
Return the correct foreground colour from this function for hyper links,
it's different from the default text colour for the links.
This makes it easy to reuse this colour for the link-like elements in
the application code.
Get the colour actually used by the theme part we use for the status bar
in the dark mode, which is quite different from the default background
colour (0x333333 vs 0x202020).
This is notably important for the controls that live inside status bar
panes, as they must use the correct background colour to blend in.
For now this is just the same thing as GetFromPoint(center-of-rectangle)
but it's already more convenient to use and it will also be changed in
the upcoming commits.
This partially undoes the changes of bc23b1f4f0 (Use wxBaseArray instead
of object array for wxAuiToolBarItemArray, 2023-04-11) as they broke the
existing code using wxAuiToolBar because the pointers to the tools were
not stable any more.
At least avoid the use of the ugly -WX_DECLARE_USER_EXPORTED_OBJARRAY()
macro by just using wxBaseObjectArray<> directly, which is simpler now,
after the change in the parent commit.
Add a trivial test checking that pointers to wxAuiToolBar tools remain
stable when more tools are added.
Closes#23514.
This key produces events with different key codes in wxMSW (WXK_CLEAR)
and the other ports (WXK_NUMPAD_BEGIN), so add a new constant to allow
to refer to it under the same name everywhere.
Also generate a key event for it in wxOSX where it previously wasn't
generated at all.
Closes#23478.
Closes#23491.
This changes of 4713301cf5 (Fix font and thumb size of wxSlider after
DPI change, 2019-08-27) fixed updating the slider thumb length on DPI
change, but this happened too late because it was done after executing
the user-defined handler for this event which could have updated the
slider size, which led to a call to its overridden DoMoveWindow() which
would use the old thumb length, resulting in the size remaining too big
when switching from higher to lower DPI and, worse, too small (and not
showing the thumb entirely) when switching in the other direction.
Fix this by updating the thumb length earlier, by using the just added
MSWBeforeDPIChangedEvent() for doing it instead of doing it in the event
handler.
This is unusual, but this function may need to rescale some coordinates
and it's convenient to just call event.Scale() then.
So pass it the event that we are preparing to process to it instead of
passing it new and old DPI separately and forcing it to deal with them
itself (instead of using Scale()).
This didn't work correctly when switching from higher to lower DPI if
the frame had a status bar because this status bar still had its old,
bigger height, by the time SetClientSize() was called from the event
handler, resulting in the frame size becoming too big.
It notably resulted in having an unwanted gap between the frame contents
and the status bar if the event handler called GetSizer()->Fit().
Fix this by calling PositionStatusBar(), which also updates the status
bar height to correspond to the new DPI as a side effect, from a new
virtual MSWBeforeDPIChangedEvent() function which had to be added to
allow wxFrame to customize DPI handling.
Adding this new virtual function just for this isn't great, but the only
alternatives seem even worse.
This was done back in 0cd159592e (save the current status text for each
pane inside wxStatusBarPane [...], 2009-02-09), but without any real
explanation about why is it needed and doesn't seem useful. Besides,
doing this requires updating this DC in several places, so just don't do
it and create the DC only when we need it.
Use a vector of unique_ptr<> to manage memory automatically instead.
No real changes, this just simplifies the code and makes it more robust
by making it impossible to forget to delete a tooltip.
There doesn't seem to be any reason to have it in GetSize() and
GetDimension(), where they were added by 0c00c86faf (fixed dialog units
in toplevel windows (bug #1170234), 2005-03-28), but not in this
function, so add it here as well.
Clarify that it is 1 by default in the documentation, instead of
implying that it's off by default and needs to be enabled.
Improve the description of this option in setup.h files.
And also document this compilation option in the summary page.
As all ports use the same CRT, it makes more sense to check for Darwin,
rather than wxOSX, in wxEnsureLocaleIsCompatibleWithCRT(), as other
ports such as wxGTK would also be affected by this problem if they were
to be used under macOS.
This doesn't make any sense, native image list implementation is only
needed for interoperability with the native controls which are not used
by wxUniv, so always use the generic version in it instead.
No real changes, just refactor the code to use this function instead of
calling setlocale(LC_CTYPE) twice.
This makes it more clear what we're doing and will make it simpler to
get rid of this when we don't have to do it any longer.
Return the actual MIME type extracted from the Content-Type header from
the existing function and also add new wxWebResponse::GetContentType()
returning the full value of this header.
Closes#23461.
It gives the following error:
The application has failed to start because its side-by-side configuration is incorrect
Fix this by specifying the xml namespace. Examples on the Microsoft website use v2, so change this too.
Fix the wrong merge done in ae13d70ddc (Merge branch 'use-std-hash',
2023-04-18) which forgot some fix ups.
Notably restore wx/wxcrt.h inclusion and fix linking wxWebRequest unit
test.
See #23462.
Fix some issues and streamline regeneration process:
- A few glitches (like duplicate language symbols, wrong Windows
language ids etc) were fixed.
- Scripts were added to allow to regenerate the list of supported
locales from the list of known Windows locales.
- Version info when language symbols became available was added to the
documentation of the language symbol enum.
- Synonyms are no longer hard-coded in the script genlang.py.
See #23453.
Closes#23437.
Replace a wx synonym with the direct use of the standard class.
Also store std::unique_ptr<> instead of raw pointers in this map to
ensure that they get destroyed: previously we could have memory leaks if
some objects were not unregistered before the program exit.
Replace wx hash maps of tags and file type data with the standard
containers.
Also use auto instead of the explicit iterator type in the code using
these maps.
We can simply check if m_attrs is empty instead.
This was added back in 696e1ea0b7 (in the
last millennium) and apparently there was no simple way to check if
wxHashTable used for m_attrs back then was empty, but it's trivial to do
it with std::unordered_map<>.
