Reference count of the source Cairo context should be increased to prevent source context from being destroyed in wxGraphicsContex dtor (where cairo_destroy is invoked).
When wxGraphicsContext is created from wxPrinterDC then also logical scaling factor applied to the source wxPrinterDC has to be explicitly applied to the Cairo context.
All inherited transformation settings should be used only internally by wxGraphicsContext object and shouldn't be exposed through e.g. GetTransform() function and hence they are stored separately (in a dedicated variable) and "subtracted" from actual transformation settings for reporting purposes.
Closes#17496.
Modification of the mapping mode of underlying DC encapsulated in wxPrinterDC (from MM_ANISOTROPIC to MM_TEXT) which is done prior to creating Cairo context affects the value of device origin which needs to be applied to the Cairo context. Due to the change of the mapping mode it has to be rescaled based on the current scaling factor value.
See #17496.
The macro wxGCC_WARNING_RESTORE is being used without a parameter which
MSVC warns about. Fix by passing the same parameter as when using
wxGCC_WARNING_SUPPRESS, namely deprecated-declarations.
Regression since b58c87db28.
APIENTRY is unconditionally defined through windows.h while it already has
been defined previously in oglpfuncs.h, resulting in a macro redefinition
warning. In this case fix the warning by undefining the macro prior to
including windows.h.
Because of using a jump in an asm block there is a warning regarding
disabling global optimisations (for that function only) and as a result of
that another warning about being unable to check for buffer overruns. To
work around the warnings temporarily disable both (C4740 and C4748).
Regression since e405bf1607.
The return NULL statement at the bottom of
wxAuiXmlHandler::DoCreateResource() is never reached because the catch-all
else branch above it always returns. Fix by removing the bottom return
statement (same as how other *XmlHandler::DoCreateResource() methods
handle this, and not by changing the else into an else if).
When wxGraphicsContext is created from "native" Cairo context (cairo_t*) then transformation settings applied initially to the underlying source Cairo context need to be stored (in a dedicated variable) to make possible determining what transformations were applied to wxGC instance since its creation. Only these explicitly applied transformations are reported by GetTransform().
1. Because Cairo uses internally GetClipBox Win API to determine surface size so we can employ the same approach in wxGraphicsRenderer::CreateContextFromNativeContext and just call this API instead of executing complicated code to determine size of underlying objects selected into DC.
2. Determine context size (and initialize respective data members with proper values) for wxCairoContext created from wxWindow.
3. Initialize respective data members with 0 values for generic wxCairoContext (with no source object provided).
Since raw DC (encapsulated in source wxDC) can be modified in wxCairoContext explicitly (e.g. when context is instantiated from wxPrinterDC or wxEnhMetaFileDC) or implicitly (by some Cairo functions) we have to store its state in ctor and restore it in dtor to assure consistent state of the source wxDC.
When not using MinGW the value NO_ITEM (-1) is passed as an item count to
the macro ListView_ApproximateViewRect. While Windows/Platform SDKs since
at least 6.0a cast the argument to (only!) a WPARAM, older ones such as
5.0 don't which results in a signed/unsigned mismatch (converting -1 to
WPARAM, which is an UINT_PTR).
Fix by always casting to WPARAM when using ListView_ApproximateViewRect.
Also use a value of -1 again instead of NO_ITEM because the latter is a
bit of a misnomer in this case (as it refers to the total number of items
in the control) and to reduce the risk of the cast being removed in the
future as well as differentiate it from the MinGW headers issue.
Note that this is a different casting problem than with other ListView_XXX
macros such as ListView_GetNextItem (which cast to int first and then to
WPARAM) where casting to WPARAM results in a warning with WIN64 builds.
That situation does not apply to ListView_ApproximateViewRect.
Regression since 00c63cfd3a.
Check the value of the wxDataViewCtrl pointer parameter in Init() instead
of unconditionally calling GetModel() on it. The default ctor of
wxDataViewEvent calls Init() with a null pointer.
This fixes the failing GUI tests with the XP buildbot slave.
Regression since 9829446755.
Also see #12649.
Unlike the other operators, we comparing for equality has a well-defined
semantics even for invalid objects, so there doesn't seem any reason to not
allow it.
Avoid duplicating the same code, even if it's trivial, in both places.
Notice that these functions are implemented in terms of operators and not vice
versa because we have no functions corresponding to operator<=() or
operator>=().
MinGW only supports "%z" directly when using ANSI stdio, but this is not
always the case (even if it often is, as just including any standard C++
header enables ANSI stdio as a side effect). Translate "%z" to "%I" for it as
well as for MSVC to ensure that it always works.
Closes#17492.
ChangeFmtChar(), used only to replace "%z" with "%I" when using MSVC, was
buggy and forgot to increment the pointer to the next format character,
meaning that the "I" we wanted to insert into the format string was simply
lost, overwritten by the next character ("d", "u" or "x").
This actually didn't change anything in 32 bit builds, but it did result in
not using the correct size in 64 bit ones, e.g. using "%zx" with (size_t)-1
output only "ffffffff" instead of the correct "ffffffffffffffff".
See #17492.
This test, added in 06458cb89f, is useless as it
doesn't matter what the value of __USE_MINGW_ANSI_STDIO when compiling the
library is, as the real wprintf() implemented used by wxPrintf() is chosen
depending on __USE_MINGW_ANSI_STDIO value when compiling the application as
wxPrintf() is defined inline.
Just remove it because "%ls" works in both cases anyhow, so always use it with
MinGW.
Iterating over bit values with wxAlphaPixelData sets the internal wxBitmap's "has alpha" flag but we want to left it unchanged so we have to save its original value and restore it afterward.
The code in QueryBgBitmap() and MSWPrintChild() is sufficiently different that
we can't easily reuse the drawing calls between them, so don't tie ourselves
in knots trying to do it, just duplicating these 2 calls in the 2 functions is
not that bad and the code is more clear.
No real changes.
Determine actual size of wxCairoContext created from native DC and HWND. This allows to report proper size of wxGraphicsContext created by wxGraphicsRenderer::CreateContextFromNativeContext / CreateContextFromNativeWindow.
When wxGraphicsContext is created from wxWindowDC or wxMemoryDC then transformation settings applied initially to the underlying source Cairo context need to be stored (in a dedicated variable) in order to have ability to determine what transformations were applied to wxGC instance since its creation. Only these explicitly applied transformations are reported by GetTransform().
Closes#17491.
When wxGraphicsContext is created from wxWindowDC then transformation settings already applied to the source wxWindowDC are not passed directly to the Cairo context through underlying GdkDrawable and therefore they need to be passed to the context explicitly.
These inherited transformation settings should be used only internally by wxGraphicsContext object and shouldn't be exposed through e.g. GetTransform() function and hence they are stored separately (in a dedicated variable) and "subtracted" from actual transformation settings for reporting purposes.
See #17491.
Using "r.x + r.width" didn't really make much sense, it just happened to be
close enough to the real value to not create any problems when using LTR
layout, but was wrong in RTL, resulting in visible vertical line being visible
in the notebook client area.
Fix this using the same GetThemeBackgroundExtent() for determining the bitmap
size as is used for drawing over it.
To correctly compute the brush origin offset for painting background of a
child in a window using RTL layout, we need to offset it by the child origin
i.e. its _right_ top corner in this case and not the left top corner as we did
before.
Conveniently, although not very explicitly, MapWindowPoints() already takes
care of this for us if we just pass it both the left and right points, but we
wrongly passed it only a single one, so it couldn't work its magic in this
case.
Change this to fix the drawing artefacts which appeared over wxNotebook
children with transparent background (e.g. wxStaticText) due to the use of
wrong origin before.
Don't define BeginRepositioningChildren() and EndRepositioningChildren() at
all in this case instead of defining them as "do nothing" functions because
BeginRepositioningChildren() still needs to return a bool, so the old code
didn't compile and we would need to add another "#else" to fix this -- instead
make it simpler by just not compiling at all in this case.
Under wxGTK print preview is created on wxMemoryDC and hence wxGraphicsContext should be created also for this kind of wxDC in MyApp::Draw.
Closes#17489.
When wxGraphicsContext is created from wxMemoryDC then transformation settings applied to the source wxMemoryDC are not passed directly to the Cairo context through underlying GdkDrawable and therefore they need to be passed to the context explicitly.
These inherited transformations settings should be used only internally by wxGraphicsContext object and shouldn't be exposed through e.g. GetTransform() function and hence they are stored separately (in a dedicated variable) and "subtracted" from actual transformation settings for reporting purposes.
Closes#17482.
Under wxGTK the default button in wxMessageDialog with style wxOK was set to
"Cancel", whether the wxOK_DEFAULT style was specified or not.
Now it is set to "OK", as expected, and wxCANCEL_DEFAULT needs to be
explicitly specified to focus the "Cancel" one.
Closes https://github.com/wxWidgets/wxWidgets/pull/267
Focus the text control after changing its value, this ensures that all text in
it is initially selected, allowing the user to easily replace it if necessary.
This was also the intention of bd9171c2ad, but
it was insufficient for wxGTK where changing the text control value seems to
reset its selection, unlike in wxMSW where the selection is preserved.
See https://github.com/wxWidgets/wxWidgets/pull/266
When wxGraphicsContext is created from wxMemoryDC with selected 32bppp wxBitmap then transformation settings applied to the source wxMemoryDC are not passed directly to the Cairo context through underlying HDC and therefore they need to be passed to the context explicitly.
These inherited transformations settings should be used only internally by wxGraphicsContext object and shouldn't be exposed through e.g. GetTransform() function and hence they are stored separately (in a dedicated variable) and "subtracted" from actual transformation settings for reporting purposes.
See #17482.
The given value in wxTextEntryDialog was not preselected as it was likely intended by the code because the SelectAll-Method of the wxTextCtrl was called before the value was set. Now the SelectAll-Method is called after setting the value in wxTextEntryDialog::TransferDataToWindow.
Don't hard code the width of spin buttons in wxGTK, this more or less worked
for GTK+ 2 (at least with the default theme, it was perfectly possible that it
also didn't work with some other ones), but not at all with GTK+ 3 where the
buttons are much wider than the hardcoded value.
Instead, do the same thing as wxSpinButton wxGTK implementation already does
and force the GTK+ widget to compute its preferred size as we need it, i.e.
without taking the text width into account, by forcing the width of the text
entry to 0.
Notice that for GTK+ 3.12+ we also need to set the max width to 0 as well to
prevent the entry from making itself big enough for that many characters,
see #17051.
This partially undoes 0a3057b83c which wrongly
modified the generated interface/wx/stc/stc.h file, as these changes were lost
after regenerating it again.
Unfortunately it doesn't seem possible to have @since annotations for the
Scintilla methods currently, ideally the generator script should be modified
to allow this, somehow.
See #17481.
