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.
