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.
Some operations on wxBitmap involve converting the internal representation
from DIB to DDB, and when this is done it can happen that the resulting DDB
will have different colour depth than source DIB because CreateDIBitmap()
Windows API which is used for conversion purposes can create DDB with
"whatever bit depth your reference DC is".
Therefore after every operation which directly or indirectly employs
CreateDIBitmap() it is necessary to update respective data member with the
actual color depth of the obtained DDB.
Closes#17479.
Closes https://github.com/wxWidgets/wxWidgets/pull/265
Sometimes the file dialog changes the current directory even if it is
cancelled, so restore it in any case, not only after successful return.
Closes https://github.com/wxWidgets/wxWidgets/pull/263
When Cairo surface is created from 32bpp wxBitmap then there is necessary to provide a location of its bit values to cairo_image_surface_create_for_data function and hence bitmap selected into wxMemoryDC has to be converted to DIB, if it is not a DIB already.
Moreover, if 32bpp bitmap doesn't contain real transparency data (is 0RGB bitmap) then its alpha values have to be corrected and set to wxALPHA_OPAQUE value (255).
Closes#17469.
Return the size of the entire virtual screen, possibly composed from multiple
monitors, rather than just the size of the primary monitor.
This makes this method consistent with wxScreenDC actually representing the
entire virtual screen and not just the primary monitor and also with wxGTK.
Closes#13279.
Scintilla conversions use UTF-16, as indicated by their names, while wxString
uses UTF-32 under Unix, so they don't work correctly for the characters
outside of BMP.
Simply use our own UTF-8 conversions, it doesn't seem possible to get invalid
UTF-8 sequences here anyhow, so the comment saying that Scintilla functions
are used to avoid asserts doesn't seem to be relevant.
Closes#15621.
The function such as fn_str(), wc_str(), and ToAscii() have
configuration-dependent return types, yet different variants were claimed to
be member function overloads. This is incorrect, as a member function cannot
be overloaded only by its return type and, for any given platform/build
variant only one of them is available.
Closes https://github.com/wxWidgets/wxWidgets/pull/260
32bpp wxBitmaps selected into wxMemoryDC can represent either 0RGB or ARGB bitmaps and hence there is necessary to instruct renderer how to interpret 32bpp contents while creating a wxGraphicsContext. wxBitmap::HasAlpha() flag is used for these purposes and its value is passed to wxD2DContext ctor (wxD2DContext is used internally as a backend D2D component) and next used to configure physical renderer created with ID2D1Factory::CreateDCRenderTarget.
Closes#17465.
cairo_surface_create_similar_image() introduced by the changes of
d6afb66388 is only available in 1.12 and later,
check for it being available and fall back to cairo_surface_create_similar()
with older versions.
This should fix Travis CI builds.
Not onlu has Scintilla no support for RTL languages, it is rendered into
a mirrored DC on Windows and so guaranteed unreadable and unsable. Fix
it by explicitly setting the window's layout direction to LTR.
