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.
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.
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.
Fixed creating wxCairoBitmapData from 32bpp wxBitmap (with and without alpha channel). This also fixes wxCairoRenderer::CreateBitmap method.
1. 32bpp bitmap can represent under MSW either ARGB or RGB bitmap so there is necessary to examine its real contents with wxBitmap::HasAlpha function.
2. ARGB bitmaps are premultiplied and there is not necessary to premultiply them again.
There is nothing we can do about these (harmless) warnings, so just
disable them. Also make sure that the header is included via
wx/msw/wrapshl.h everywhere.
Expand() called ExpandAncestors() in the generic wxDataViewCtrl implementation
but not in the native ones, resulting in observable difference in the
behaviour: for example, the wxDataViewTreeCtrl in the dataview sample appeared
initially expanded under MSW, using the generic version, but collapsed under
GTK and OSX.
Harmonize this among all ports. This also has a nice side effect of making
Expand() less horribly inefficient as it is not recursively called by
ExpandAncestors() which it itself used to call: now ExpandAncestors() only
calls DoExpand() which is a simple function that only expands the item passed
to it and does nothing else.
Closes#14803.
The code handling background colour was commented out for some reason, simply
enable it as it seems to be working just fine -- and update the sample to show
that it does.
Refresh(&rect) was used instead of Refresh(true, &rect) mistakenly, thanks to
clang for warning about always-true-conversion-to-bool here.
Fix this by using less error-prone and more clear RefreshRect().
Partially undo the changes of e417913f46 and set
m_item in StartEditing() as it's supposed to be already set when
CreateEditorCtrl() is called and setting it in NotifyEditingStarted() was too
late for this.
Take care of all the common stuff such as setting the event object and the
model, which is used for all events, in the ctor. Also set both the column
pointer and the column index at once instead of having two separate setters
for them which could result in inconsistent event objects (and did, as
sometimes only one or only the other field was set).
This makes the code shorter (we save 160 lines) and more clear and ensures
that everything is always initialized.
Closes#12649.
Using wxELLIPSIZE_END together with wxALIGN_RIGHT resulted in unnecessarily
ellipsizing or truncating the column contents in generic wxDataViewCtrl under
MSW due to the combination of b642747fd2 and
the native API behaviour.
Fix this by not using alignment in RenderText(): it is unnecessary anyhow and
not doing it avoids the problem as a side effect.
Closes#17363.
Caching the best column widths broke autosizing behaviour if the column title
was updated after setting the width to wxCOL_WIDTH_AUTOSIZE.
Fix this by invaliding the column cached width if its text changes.
As we do it for MinGW now, do it also for MSVC in a similar way: this is more
straightforward and less annoying than raising an exception (which can be
caught by a debugger and, at least, is logged by it) and ensures we use
similar code for MinGW and MSVC which should hopefully minimizing the risk of
breaking one or the other without noticing in the future.
Normally there should be no changes in behaviour.
