This reverts commit 8395e5733d because
HTTP standard says that senders MUST NOT generate multiple lines with
the same header, with the only exception of Set-Cookie, so we shouldn't
provide a way to do it.
That commit also introduced a nasty regression with the programs calling
AddCommonHeader("User-Agent") not working at all any more after it
because WinHTTP refuses to send a request with multiple copies of this
header.
Also partially reverts 1000d67c13 which
was done later but is logically part of the same commit that is being
reverted.
See #24881.
This was already done when reading files and we should also produce
files in UTF-8 on output.
The only significant part of the change is the removal of wxConvCurrent
argument to Write(), removing wxConvAuto() doesn't do anything as it's
the default anyhow.
Closes#25008.
Setting m_hasMaximized=true, as the existing code in LoadPerspective()
did, is not enough to make the pane really maximized, and doing this
resulted in broken layout when restoring a layout with a maximized pane.
Fix this by calling MaximizePane() instead.
Note that this function only works if passed a reference to one of the
panes managed by wxAuiManager and not its copy, so we must use GetPane()
to get the proper pane to use.
See #25004.
Closes#24990.
This includes multiple tab controls and pages order and uses new
wxAuiSerializer and wxAuiDeserializer notebook-specific functions.
These functions are pure virtual, which may be inconvenient if the
program doesn't use wxAuiNotebook at all or doesn't allow splitting or
reordering their pages, as it forces to still define them in this case,
but this is arguably not too burdensome and making them pure virtual
helps to attract attention to the fact that they need to be implemented
for saving notebook layouts.
Update the sample to show how to support notebook layout serialization
in the simplest possible way, by creating a separate top-level XML tag
for the notebooks. It could be tidier to put information about them
inside the corresponding pane tags, but doing it like this is simpler
and more clear, which is important for the sample code.
Closes#24950.
This shouldn't be necessary now as they use the same CSS colour names
that we use too by default and like this switching to "Traditional"
colour names also changes wxGTK behaviour to use wxMSW colour values.
We don't need to create ~200 colours of which we're probably only going
to use only a few on program startup, so don't do it and really create
them only when they're really needed.
Allow reverting to using the traditional values for the conflicting
colours by calling UseScheme(Traditional) if really needed.
This is another attempt for changing wxColourDatabase to use more
standard colour values, after the previous attempt in bb131fdbc5
(updated colour definitions to the new official X version (patch
771272), 2003-07-17) which was reverted almost immediately after in
5e2ab1ea5d (reverted the last change (colour values changes), it cerated
too many problems, 2003-07-19), see #6031. Unlike the previous ones, it
provides an escape hatch in the form of UseScheme() and also leaves
traditional wx colour names not clashing with CSS ones still available.
Also update the "drawing" sample to allow showing both colour schemes,
and extend its view port to fit all the colour names vertically.
See #23518.
This makes things simpler, removing an interdependence between
wxStockGDI and wxColourDatabase, and isolates the grey and medium grey
pens and brushes from the upcoming change to the value of the latter
colour in wxColourDatabase.
Note that we intentionally don't add wxGREY and wxMEDIUM_GREY macros,
unlike for the existing stock colours, as they are not really necessary
and it doesn't seem worth to add them just for consistency, especially
because it's easy to imagine some existing code already defining them,
especially the former one.
No real changes yet.
Just add the GRAY variants to the database directly instead of checking
for both GREY and GRAY when looking the colours up.
Note that we don't automatically add the version using GREY if a colour
with GRAY in it is added explicitly via AddColour() as this is not
something that had ever been documented and doesn't seem to make much
sense: application programmer using "GRAY" when adding a colour is
unlikely to use "GREY" when retrieving it later.
No real changes, just remove special handling of wxTheColourDatabase
which was allocated, together with the other global lists, in
wxInitializeStockLists() but deleted in wxAppBase::CleanUp() from where
wxDeleteStockLists() was called instead of in that function itself.
Remove this discrepancy.
Add forgotten destructor.
This should have been even more part of hastily pushed 0f26d71bb7 (Merge
branch 'msw-stattext-markup', 2024-12-12), see #25000.
This ensures that it is redrawn even when wxST_NO_AUTORESIZE is used.
This should have been part of 0f26d71bb7 (Merge branch
'msw-stattext-markup', 2024-12-12), see #25000.
Replace most 'neither' words introduced after 2b0ee48ef7
(Fix double negatives used with 'neither', 2023-11-25)
with 'either'.
All changes are to comments only.
Closes#24999.
This new struct will be used by wxAuiNotebook too in upcoming commits,
so extract it from wxAuiPaneLayoutInfo and extract the code used for
copying the layout information between it and wxAuiPaneInfo to the new
functions to allow reusing them from wxAuiNotebook code.
It's already part of wxAuiNotebookPage also passed to its AddPage() and
InsertPage() functions and there is no need to pass it as a separate
parameter.
This changes these functions in a backwards-incompatible way, and even
though they were never really supposed to be public, provide
backwards-compatible overloads for them just in case somebody used them.
No real changes, just simplify the code.
This can be useful to find the actual page position on screen, inside
its containing tab control, as opposed to its logical index.
Use the new function to show pages in their visual order in the AUI
sample.
Always keep the pages in wxAuiNotebook::m_tabs in the order in which
they were added or inserted and only change their order in the tab
controls when they are interactively reordered by user.
Refactor page insertion code so that the new InsertPageAt() helper
function can be called from the code handling dragging tab to another
wxAuiNotebook too, instead of reproducing what it does there.
Also test InsertPage() in the sample.
This effectively reverts ab67e8874d (Fix wrong tab order in
wxAuiNotebook after dragging., 2012-12-23), see #10848.
It is not necessarily obvious that the pages are always added to it and
not being inserted into the position determined by the insertion index,
but this is the case now, so document this behaviour.
Don't handle the case of having 1 or 2 pages specially, there doesn't
seem to be any good reason to do it, especially because splitting the
notebook programmatically by dragging the pages around doesn't do it.
We can simplify things by serializing the dock size, which is the only
information about them which is not recomputed by wxAUI itself when
redoing layout, as part of the panes layout data.
This is a bit inelegant because the same size is stored for all panes
that are part of the same dock, but it makes writing serializers and
deserializers significantly simpler, as they now only have to deal with
one kind of objects, and so seems to be worth it, especially because
with the previous approach we stored even more redundant data, with the
dock direction, layer and row duplicated between the dock itself and all
the panes contained in it.
This change will also make it much simpler to serialize the layout of
nested AUI managers, such as the one used by wxAuiNotebook, later.
Vadim Zeitlin
Blake-Madden
Lauri Nurmi