This solves backward incompatibility problem introduced in 2d8bbbe3c9.
The name of base class for grid header renderers hierarchy is restored
to be wxGridHeaderLabelsRenderer. This introduces another problem: now
wxGridCornerHeaderRenderer is derived from wxGridHeaderLabelsRenderer,
not vice versa, as it was before. But it is considered less disruptive
change, compared to base class rename.
Now, every header cell can have a label, including the corner one,
so wxGridHeaderLabelsRenderer::DrawLabel() was moved up one level
in the inheritance chain. Class names were changed accordingly.
Actual storage of corner label is delegated to a grid table class,
just because it is already done that way for column and row labels.
Move the entire contents of wxAdv library into wxCore.
In the future, wxAdv will disappear entirely, but for now keep it as an
empty placeholder to allow the existing make/project files to work.
See https://github.com/wxWidgets/wxWidgets/pull/900
* Switch to pure Core Text Implementation, Start extended Font API
* mac fixes
* First msw implementation
* Fixing paste error
* fixing typo
* Rearranging lines to former fallthrough order
* Blind fixes for covering new abstract methods
* Blind gtk implementations
* Fixing according to travis ..
* Removing method defined in base
* formatting adaptions
* Extending the schema definition for new weights
* fixing typo, using wxRound, other fixes according to comments
* changes according to suggestions
* fixing init order, before the init of m_info was overridden by Init()
* redo
* redo
* redo
* Cleanup
Removing obsolete code snippets, proper traces for font names
* Moving common code
Only the Get/SetNumericWeight calls should now be implemented in the native part, the ‚old‘ Get/SetWeight are common code and use the numeric counterparts.
* Updating docs
* commit wa missing changes.txt
* Doc fixes
* Full stops added
This basically removes the "adv" library, even though it's still
preserved for compatibility with user make/project files referring to
it.
It is done because the distinction between "adv" and "core" was never
really clear (e.g. why wxTreeCtrl was in core but wxTreeListCtrl in
adv?) and it prevented some core classes from using adv ones.
Make m_Parser and m_FS simple objects instead of pointers as it's
completely unnecessary to allocate them on the heap here.
Note that both wxHtmlWinParser (by explicitly including its header) and
wxFileSystem (which is implicitly included via wx/html/htmlpars.h) are
fully declared in the header, so using pointers doesn't even help with
reducing compilation dependencies.
No real changes.
This is more efficient when the same HTML is reused multiple times, e.g.
for measuring it first and then rendering it.
The new function also makes it simpler to parse HTML and manipulate it
in some way before measuring and rendering it.
Add wxWebViewEvent::GetNavigationAction() returning a value that can be
either wxWEBVIEW_NAV_ACTION_USER for the links opened by the user, or
wxWEBVIEW_NAV_ACTION_OTHER for the other ones (e.g. opened from
JavaScript code on the page).
Closes#15402.
* First attempt using ref data for colour and spliting implementation for CGColorRef and NSColor
* correcting SDK dependency
* Implementing feedback suggestions
Ignore all the mouse events other than "left up" while dragging to avoid
releasing the mouse and ending the dragging operation too soon.
This required non-trivial refactoring of the code which hopefully should
also make it slightly more clear by centralizing high level logic in
ProcessGridCellMouseEvent() itself and calling various helper functions
from it instead of spreading this logic over the entire call tree.
The code still remains pretty confusing and rewriting it to use
wxMouseEventsManager (which would need to be generalized first to become
a template class using arbitrary item type instead of just "int", as
now) would undoubtedly do it a lot of good.
Closes#18186.
No real changes, just refactor the code to extract the part of
CancelMouseCapture() which can be useful not only when the mouse capture
is lost unexpectedly, but also when we release it of our own volition,
into a separate function.
clang doesn't seem to like __declspec in typedefs, so declare the class
first using the macro expanding into __declspec and don't use it in the
typedef later.
Closes#18196.
Implement support for this attribute only in the generic version so far,
it will hopefully be implemented for the natives ones in the future.
Also add a new toggle column to the dataview sample to check how it
works: checking the items in this column enables using this attribute
for some other ones.
Closes#18180.
removing 'inline' did fix:
warning: 'virtual void wxSystemThemedControlBase::DoEnableSystemTheme(bool, wxWindow*)' redeclared without dllimport attribute after being referenced with dll linkage
but introduced
multiple definition of `wxSystemThemedControlBase::DoEnableSystemTheme(bool, wxWindow*)'.
The proposed form gets no complaints
Make the (originally) auto-generated code of this dialog slightly more
readable by replacing some auto-generated variable names with more clear
ones.
Also avoid using FindWindow(), this is useless and we already have the
window pointers.
Closes https://github.com/wxWidgets/wxWidgets/pull/872
Base class SetTitle() implementation didnd't work for this class as it
used the (invalid) HWND of not yet existing dialog, so add a hook
procedure for the common font dialog, similar to the existing one for
wxColourDialog, which allows us to set the dialog title when the dialog
is really created.
Closes https://github.com/wxWidgets/wxWidgets/pull/865Closes#18177.
Add a check ensuring that if wxCheckListBox is disabled, then so is
wxRearrangeCtrl, to avoid build errors that would happen otherwise.
Closes https://github.com/wxWidgets/wxWidgets/pull/866
It was impossible to stop sorting the control if it had been sorted
before, so implement UnsetAsSortKey() to allow doing it by destroying
the current sort descriptor.
Closes#18176.
Previously, wxEVT_{SET,KILL}_FOCUS event handlers were connected to all
children, even the indirect ones, which resulted in duplicate focus
events if a grandchildren forward its focus event to its parent window,
as happens e.g. with wxComboCtrl, which contains a text control that
forwards its focus events to the containing control itself.
This change seems globally sound, even if it might break some controls
whose children don't get the expected focus events themselves, because
the right thing to do is to fix those children. And it fixes duplicate
focus events in wxDatePickerCtrlGeneric.
Revert 1de107c037 and remove the focus
event handler which duplicated and interfered with the handler inherited
from this class to make sure that we get wxEVT_{SET,KILL}_FOCUS for the
objects of this class.
Unfortunately these events now come in pairs, due to an extra artificial
event generated by wxComboBoxExtraInputHandler::OnFocus(), which is
still wrong -- but arguably less wrong and more useful than not sending
them at all.
This fixes a compilation error in wxMSW private fonts support
implementation, which compares wxString with a wide string but, unlike a
local fix there, makes sense more broadly and should reduce the
likelihood of similar errors in the future.
It also makes comparisons with narrow C strings more efficient in the
default, Unicode, build by using wxString::Cmp() method instead of
creating a temporary wxString, as was done before.
See #18172.
While this doesn't make, and never made, any sense (pointers should be
stored in a plain, non-object array), we still should continue to
support it for compatibility.
Fix the problem introduced by 97684a9267
by writing "T const&" instead of "const T&" as the latter didn't have
the same meaning when the macro parameter "T" expanded into "U*" as
"const" applied to "U", making this type incompatible with the actual
one.
Also extend the unit test to check for this.
Changing item cell in ShowAsRadio() was wrong as the item cell doesn't
exist when it is called and changing the column cell didn't seem to work
well, so just recreate the entire cell in it instead.
See https://github.com/wxWidgets/wxWidgets/pull/853
Avoid stringop-overflow warning about strncpy size argument depending on source size.
Checking for null in src is not needed because it is already checked by strlen.
This allows showing radio buttons in wxDataViewCtrl easily and natively.
Notice that this approach, adding an extra function to the existing
renderer class instead of creating some new wxDataViewRadioRenderer (see
https://github.com/wxWidgets/wxWidgets/pull/809), was finally chosen
because it is simpler to implement and, more importantly, because it
will be more natural to generalize if/when we also add a 3-state
check/radio renderer.
Closes https://github.com/wxWidgets/wxWidgets/pull/853
Changes of c0b0562533 to common code broke
wxGTK1 build, as wx/gtk/private/wrapgtk.h is for wxGTK 2+ only.
Fix this by handling wxGTK 1 separately and including gtk/gtk.h directly
for it.
Hopefully this code will be removed, together with the rest of wxGTK1
support, in some not so distant future.
This is especially important under MSW, where the modality of the nested
event loops actually ends as soon as wxModalEventLoop::Exit() is called,
and so we must avoid dispatching any events in the current loop after it
happens or we risk reentering the same loop again, which could result in
e.g. parent modal dialog being closed before the child event loop
returns (because the event closing the former was dispatched from the
latter) and other unexpected sequences of events.
To prevent this from happening, only dispatch pending events after the
loop exit if it's the outermost loop, as there should be no danger in
doing it in this case. Conversely, we don't lose anything by not doing
this in nested event loops as the outer loop will take care of any
remaining pending events anyhow.
To make this work in an ABI-compatible way, add a global counter of the
currently existing event loops which is used to check if there is more
than one event loop currently running.
Closes#11273, #11573, #11269.
Apply DPI scaling to the extra vertical margin added by this macro to
the font height.
This makes sense and results in wxTextCtrl (and other controls, e.g.
wxSearchCtrl) having the same height as native ones when using high DPI
too.
Note that this required adding wxGetEditHeightFromCharHeight() function
as one of the existing uses of EDIT_HEIGHT_FROM_CHAR_HEIGHT() wasn't
inside a wxWindow-derived class method and also adding wxUSE_GUI guard
around these GUI-only definitions as a function, unlike a macro, can't
be compiled without full wxWindow declaration in scope.
There is no need to override this virtual function, if the control size
changes, a wxEVT_SIZE event is generated in any case, resulting in a
call to LayoutControls() without explicitly calling it from here.
There doesn't seem to be any reason to have these flags, which duplicate
the visibility state of m_searchButton and m_cancelButton respectively.
Also update the buttons visibility immediately in ShowSearchButton() and
ShowCancelButton() instead of doing it in LayoutControls() as before,
which was confusing as laying out is not supposed to show/hide anything.
Finally, return true, not false, from IsSearchButtonVisible() if the
button is actually visible because there is an associated menu, even if
ShowSearchButton(false) had been called. This seems more logical and
makes the code simpler, but we need to check whether the native Mac
version also behaves like this or not.
No other changes in behaviour.
Checking for the exact match of __GXX_ABI_VERSION created more problems
(including for both Fedora and Debian packagers, see
https://github.com/wxWidgets/wxWidgets/pull/828) than it solved
(approximately 0), so relax it and assume that future g++ versions will
remain broadly compatible with the current ABI, which seems like a safe
assumption so far.
It's not really clear if there is any value in having this ABI check at
all, or if we should remove CheckBuildOptions() and all the code calling
it entirely, as it seems that there is no way to trigger this check
during run-time without getting a link error first. But keep it for now,
just because it's simpler to keep it than to remove it.
Just test m_blockEvents directly, there doesn't seem to be any gain in
using an accessor here.
Also test it only once instead of doing it twice in
MacHandleSelectionChange().
Prevents deselecting the selected item in single-selection listbox.
Also generate correct events in the multi-selection case by reusing the
existing wxListBoxBase::CalcAndSendEvent() method.
Closes#15603.
Passing an empty std::vector<wxString> to Append() or Insert() methods
of any wxItemContainer-derived classes, such as e.g. wxComboBox,
resulted in undefined behaviour due to accessing the first element of an
empty vector.
Fix this by avoiding using it when the vector is empty.
For some reason lost in the depths of time (but probably just a typo)
(but probably just a typo) (but probably just a typo) (but probably just
a typo), SetItem() overload taking the column index returned "long" and
not "bool", even though the actual return value was always "true" or
"false" (or even just always "true" in the case of the generic version).
Change it to return "bool" for consistency with the other overload and
because this just makes more sense and shouldn't break any existing code
due to the implicit conversions between bool and long.
Also document the return value meaning.
Closes#18153.
When wxColourDialog is shown, any changes to the colour selected in it
apparently result in broadcast messages to all currently visible text
controls, which was unexpected.
Block the changeColor: message to prevent this from happening.
Closes https://github.com/wxWidgets/wxWidgets/pull/830
Since the changes of 6ae7aa4443, the
windows were shown when their geometry was restored as a side effect of
calling ::SetWindowPlacement(). This was unexpected and resulted in
flicker on startup, so fix this by explicitly passing SW_HIDE to
SetWindowPlacement() if the window is currently hidden and storing the
real show command inside wxTLW itself, where it will be used when it's
finally shown.
This single field replaces m_iconized and m_maximizeOnShow which were
not really independent and will make it simpler to schedule either
maximizing or maximizing the window later, when it can't be done
immediately because the window is hidden, in the following commit.
Add wxHtmlEasyPrinting::SetPromptMode() to allow suppressing the
"prompt" shown by wxPrinter::Print() when it's called from this class
code.
Closes https://github.com/wxWidgets/wxWidgets/pull/838
This class doesn't have any non-inline methods and so doesn't need to be
exported from the DLL.
This also avoids warnings in MSVC DLL build about using non
dll-interface class wxArrayTreeItemIdsBase as base for dll-interface
class wxArrayTreeItemIds (C4275).
The new method returns a boolean flag which indicates whether there is
any clipping region or not and so is preferable to using the old one and
checking its return value to determine this, which can't be done
reliably.
No real changes, just call wxDCImpl::DestroyClippingRegion() from
the overridden versions in the derived classes instead of calling
ResetClipping(): this makes the code more clear as it follows the usual
pattern of the derived class doing something first and then forwarding
to the base class.
Also, as ResetClipping() is not really useful, add a comment documenting
that it shouldn't be used in the new code.
Determining whether there is an actual clipping region or not is not
that simple, as shown by the recent problems in wxDCClipper code, so
return a boolean value indicating this from GetClippingBox() directly,
instead of requiring the caller to find it out on their own.
This simplifies wxDCClipper code, as well as any other code calling
GetClippingBox(), at the price of some extra complexity in wxDCImpl
itself, which seems to be worth it.
wxDC::GetClippingBox() is actually supposed to return a rectangle equal
to the total wxDC area and not an empty rectangle if there is no
clipping box at all, so avoid restoring the old clipping region
unnecessarily in this case too: even if it should be harmless, it's
still unnecessarily inefficient and, in practice, this is not really
harmless neither as wxPdfDC (from the third party wxPdfDocument library)
doesn't handle having a clipping region set when adding a new page
correctly and so using wxDCClipper broke PDF generation.
This fixes another fallout from 2a8c290e0d
See #13834.
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.
While Windows headers compile without warnings at maximal warning level,
they still contain some warnings which are disabled by default, but can
be enabled explicitly, such as C4668.
Make life simpler for the user code doing this by avoiding giving these
warnings from the Platform SDK headers as it doesn't cost much to do
this from wxMSW itself, while doing it from the user code is nontrivial.
Don't cast function pointers of incompatible types, this resulted in gcc
8 -Wcast-function-type warnings and could hide real errors.
To fix this, overload wxBaseArray::Sort() to accept either the "legacy"
sort function compatible with qsort() or a function compatible with
std::sort(), as it seems both variants could be used before. Also make
the type of the latter function customizable via a new optional Sorter
template parameter in wxBaseArray in order to allow wxSortedArrayString
to specify its own variant of it, taking (const) references instead of
values.
This complicates things, but should preserve compatibility while being
type-safe and, also, allows to simplify _WX_DEFINE_SORTED_TYPEARRAY_2 by
not passing the sort function signature to it any more.
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.
Don't cast function pointers of incompatible types, this resulted in gcc
8 -Wcast-function-type warnings and could hide real errors.
Use normal, taking elements by value, sort function for in wxBaseArray
methods used by the sorted arrays only and provide Sort() overloads for
both this sort function variant and the compatible with qsort() one
taking pointers to the elements.
Suppress the warnings about formally incorrect but working in practice
cast from an event handler taking an object of a class derived from
wxEvent to wxEventFunction, i.e. a handler taking just wxEvent itself.
These warnings are unavoidable in a few places, and testing for gcc
version and suppressing them is too verbose, so define helper macros
making it a bit less painful.
BucketFromNode typedef must be defined as a function returning size_t,
as GetBucketForNode() method in the classes generated by hash map macros
does, to avoid warnings about bad function pointer casts in Win64 build,
where size_t is not the same thing as "unsigned long".
By now all compilers/SDKs should hopefully have {Get,Set}WindowLongPtr()
and GWLP_XXX constants, so there is no reason to keep separate, and
differing by return type in wxGetWindowProc() case (oversight?),
versions of these functions for Win32 and Win64 builds.
Combine them in a single version appropriate for both cases.
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.
Put the code implementing object arrays, i.e. arrays owning pointers to
the objects, into wxBaseObjectArray<> instead of _WX_DECLARE_OBJARRAY
macro.
Also simplify WX_DEFINE_OBJARRAY() by leaving only the definitions of
functions creating and destroying the objects in it (they have to be
there and not in the template itself to allow using template with
incomplete classes).
Add wxBaseSortedArray<> template instead of putting all the code inside
_WX_DEFINE_SORTED_TYPEARRAY_2 macro.
There should be no changes, but the code is now easier to read and
modify.
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.
Don't repeat the same check for !defined(WXUSINGDLL) many times.
No real changes, this is just a simplification (which should be viewed
with "git diff -w --color-words" to see how little has really changed).
MSVC users can simplify their projects by prepending
$(WXWIN)\include\msvc to the compiler include directories, which results
in automatic including the build-specific setup.h and linking all
required wxWidgets and system libraries.
This worked only for the default multilib builds but not for monolithic
builds where wxWidgets libraries are created and named differently.
This patch allows the users (by defining wxMONOLITHIC=1 in their
project) to use it also for monolithic builds.
Somehow this compiled with the previous gcc versions (as well as MSVS),
but a static_cast from an integer wxUIntPtr type to a pointer HANDLE
type is obviously invalid and a reinterpret_cast is needed here.
This fixes compilation with g++ 8.
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 doesn't seem to be any reason to call this function more than once
on the same cell as the existing implementations are idempotent and it's
difficult to see why this should ever not be the case.
This function was difficult to understand as it did two quite different
things depending on the value of its "dont_render" argument and using it
also made CountPages() logic more complicated than necessary.
Simplify the code by splitting Render() into FindNextPageBreak(), which
is used by CountPages(), and Render() itself, which doesn't need to deal
with pagination at all as it's either already provided the page start
and end positions or can just assume that everything fits on a single
page (the latter is the case for the headers and footers renderer).
This is a notionally backwards-incompatible change, but no code using
wxHtmlDCRenderer could be found in the wild and the new API is so much
simpler that it seems to be worth switching to it.
MSW, GTK, OSX and Postscript implementations all did almost exactly the
same thing to initialize wxPrintout, so extract this common code into a
new wxPrintout method and just call it instead.
There should be no changes in behaviour.
Include gdk/gdkkeysyms.h from wx/gtk/private/gtk2-compat.h as it must be
included before it for the compatibility header to define the new names
for the key constants even when using old GTK+ versions.
The definition of macros min and max in include/wx/msw/wrapgdip.h
b/include/wx/msw/wrapgdip.h was clashing with the new bessel functions
that use std::numeric_limits<T>::min/max.
So #include <cmath> before #include <gdiplus.h> and use using
declarations of std::min and max instead of macros.
This method doesn't modify the known page breaks, it only uses them to
find the next one, so make it more clear by using const reference in the
function signature.
There is no need to allocate these objects on the heap and delete them
later when we can just make them members of wxHtmlPrintout object
itself.
No real changes.
Add wx/gtk/private/wrapgtk.h wrapping gtk/gtk.h in pragmas disabling
these warnings and include it everywhere instead of directly including
gtk/gtk.h.
Also include wx/gtk/private/gtk2-compat.h from this wrapper header as it
was included by 90% of the files including gtk/gtk.h itself and it seems
to be better and simpler to just always include it.
The changes between 1010 (which was already considered equivalent to
1002) and 1011 don't seem to affect wxWidgets and the library compiled
with g++6 can be used from the application built with g++7 without any
problems.
There doesn't seem to be anything wrong with just showing the popup menu
in this window itself and this avoids the need to do any coordinate
adjustments, which didn't work correctly for the menus shown over the
header window after the previous commit (and hadn't worked correctly for
the menus shown over the non-header area before it).
See #18133.
Don't define GetIcon(), GetIcons() and SetIcon() at all as the base
class already implements them and just keep SetIcons(), which can now be
marked as overridden as it's inherited from wxTopLevelWindow via
wxTDIChildFrame.
This method is confusing as it's not used for implementing Show(), which
is the usual naming convention when both Foo() and DoFoo() members
exist, and gives no clear indication about what does it really do.
Just call wxWindow::Show() directly instead.
Also create the wxAuiMDIChildFrame window hidden from the beginning,
instead of creating it in a visible state and then hiding it.
There doesn't seem to be any reason for overriding DoSetSize() and
DoMoveWindow(), so just stop doing it.
Notice that this was already changed for wxGTK many years ago in
a94476deb9 and there is no reason to use
different code wxGTK and other ports.
Make it easier to use AUI-based MDI child frame class instead of
normal wxMDIChildFrame itself by inheriting it from the same base class.
This also allows to get rid of duplicate stubs in wxAuiMDIChildFrame.
The default alignment of the text in wxSpinCtrl was changed to "right"
in 7e4952db83, which added alignment
support (see #10621), but this made it inconsistent with the native
up-down control under MSW and, perhaps more importantly, with spin
controls created from XRC as the default style was never modified there
and did not include wxALIGN_RIGHT.
Resolve this inconsistency by reverting to left-aligning the text by
default.
The horizontal static line was added to separate the button from the
child window when visible, but this didn't seem very useful and looked
bad and was inconsistent with the native GTK+ implementation as well as
similar controls commonly used under MSW (wxOSX already disabled the
static line use).
Just remove it to make things simpler and better looking.
Closes https://github.com/wxWidgets/wxWidgets/pull/804
Allow using positions in the entire int range for window positions under
MSW, and not just those in (slightly less than) short range, that are
supported by the native API.
Closes#4262.
Closes https://github.com/wxWidgets/wxWidgets/pull/779
Save both the normal window geometry and its maximized position instead
of saving just its current position. This fixes restoring geometry of
the maximized windows as previously they were always restored on the
primary monitor, as their original position was lost.
Use the native {Get,Set}WindowPlacement() functions for a MSW-specific
wxTLWGeometry implementation to achieve this.
Closes#16335.
Previously, TLW geometry was implicitly defined as just its position,
size and the maximized/iconized state by wxPersistentTLW code. This
already wasn't enough for wxGTK which added the decoration sizes to the
geometry being saved/restored, but this had to be done using conditional
compilation, which was not ideal. And it didn't allow using an entirely
different geometry representation as will be done for wxMSW soon.
Change the code to use wxTLWGeometry class defining the geometry, as
used by the current port, explicitly and move wxPersistentTLW logic into
it, as wxPersistentXXX classes are supposed to be very simple, which
wasn't really the case.
Also provide public SaveGeometry() and RestoreToGeometry() methods in
wxTopLevelWindow, which can be useful even to people not using
wxPersistentTLW for whatever reason.
There should be no changes in behaviour so far.
This will allow this code to work even when implicit conversion from
"const char*" is disabled in wxString and is already marginally more
efficient even now.
See https://github.com/wxWidgets/wxWidgets/pull/782
As liblzma API is similar to zlib API, this class is also close to
wxZlibOutputStream, except that it uses reusable functions instead of
repeating their code.
Prepare for using liblzma in wxWidgets code by adding the necessary
option and updating the configure check for it (which had been already
present due to libtiff possible dependency on liblzma).
No real changes yet.
Avoid duplicating base class DoSetSelection() implementation in
wxTreebook, just extend it slightly by using DoGetNonNullPage() to allow
using a (sub-)page if the page associated to the selected item is null
and reuse it.
Also get rid of wxTreebook::m_actualSelection, it seems completely
unnecessary to bother keeping and updating it when we can just find it
whenever we need (which actually seems to only have been the case in the
now removed DoSetSelection() implementation anyhow).
As a side effect of this, wxTreebook pages should now be sizer correctly
when switching to them as DoSetSelection() in the base class does call
SetSize() on the page before showing it, unlike the previously used
version in wxTreebook, which omitted this call for some reason.
There should be no other user-visible changes.
Closes#4379.
Change m_selection in wxBookCtrlBase::DoSetSelection() itself instead of
requiring all the derived class overriding do it in their overridden
UpdateSelectedPage().
No real changes, this is just a small simplification.
Remove an unnecessary header dependency. This is not completely
backwards-compatible as it would break any code relying on getting e.g.
wxTextCtrl declaration after including wx/treebook.h, but, hopefully,
there shouldn't be that much such code out there and fixing it shouldn't
be difficult.
If either of these assumptions turns out to be false, this commit can
always be reverted later.
Added new functions SetButtonMinSizeClass() and
SetButtonMaxSizeClass() that set a button's minimum
and maximum allowed size class during ribbon layout collapsing.
Size classes are values from wxRibbonButtonBarButtonState enum.
wxRibbonButtonBar::MakeLayouts() and
wxRibbonButtonBar::TryCollapseLayout() are modified to support
this new behaviour.
The modified wxRibbonButtonBar provate layout routines are
aware of wxRIBBON_BUTTONBAR_BUTTON_SMALL which is not implemented
yet in MSW wxRibbonMSWArtProvider::DrawButtonBarButtonForeground.
Make it possible to call wxStandardPaths::MakeConfigFileName() without
explicitly specifying the convention to use, to make it conform to the
documentation (previously this only worked when calling the
wxStandardPathsBase version of the method).
Closes#18106.
Added new function SetButtonText() which modifies labels of
existing ribbon button bar buttons.
The new function SetButtonTextMinWidth() is used to specify the
label width in advance so that lables can be changed without
recalculating the layout.
wxRibbonArtProvider is modified to support these operation.
Define g_signal_handlers_disconnect_by_data() if it's not available,
i.e. when using glib older than 2.32 where it was added, to fix the
build under old systems such as CentOS 6 broken by the changes of
8278f7b618 (see #18084).
Also use it elsewhere instead of g_signal_handlers_disconnect_matched()
as it's more readable.
Closes https://github.com/wxWidgets/wxWidgets/pull/760
It seems to make more sense to round the result to int rather than to
truncate it when scaling wxSize or wxPoint coordinates by a floating
point number.
wxRealPoint uses double coordinates and it makes no sense to truncate
the result of scaling it to int -- this was almost certainly a
copy-and-paste error due to copying the code of the corresponding
wxPoint method.
There doesn't seem to be any reason to use float here when double is
used everywhere else.
Moreover, the (implicit) conversion of int to float is not always
lossless, and resulted in -Wconversion warnings from g++ 7, which
disappear when using doubles.
This is similar to a recent commit adding the missing typedefs to wxList
iterators and defines the types required by the iterator concept in
wxVector::reverse_iterator and const_reverse_iterator classes (simple
iterators are just pointers and are already covered by the standard
iterator_traits specialization).
This typedef is redundant with the "reference" one and doesn't seem to
be used anywhere.
As with the previous commit, this one could be reverted later if it
turns out it does break any existing code, but this seems unlikely.
This typedef is completely redundant with pointer_type which had been
also available in these classes since the very beginning and seems to
have been meant to be private originally, so it should be safe to just
remove it, especially because I couldn't find any existing code using
it.
If we do find such code in the wild later, this commit could be reverted
as it's not really indispensable.
Define "pointer", "reference", "difference_type" and "iterator_category"
typedefs to ensure that wxList iterator classes are seen as iterators by
the standard library in C++11 and later, as otherwise standard container
template ctors taking iterators couldn't be used with them because
they're only available if input iterator requirements are satisfied.
This notably fixes creation of std::list from wxList iterators; add a
test which didn't compile before to show it.
Escape backslashes in wxJSScriptWrapper to allow strings with
backslashes in them to work again -- this was broken while implementing
support for returning values from JavaScript to C++.
See https://github.com/wxWidgets/wxWidgets/pull/741
