When adding a new item to a wxMSW ListCtrl that uses horizontal rules the
painting is horizontally clipped to the left of the control and the
rightmost column and the rule doesn't extend beyond that as it does when
doing a full repaint. Fix by refreshing the part to the right of the
rightmost column.
This also reverts 02c8973a57 which became
unnecessary now.
Also see #17158.
Appending an item in the listctrl sample results in two horizontal lines
drawn next to each other while they should be overlapping. Fix by drawing
only the bottom line of each item instead of skipping the first one
(should have been the top visible item since
6443de0263) and drawing the last one in the
list (should have been bottom visible item).
Since 9eaba69276 a fix was added for leaving
behind trailing pixels when resizing a column in a ListCtrl that uses
wxLC_VRULES. This fix is only needed for ComCtl32.dll versions prior to
6.0. Make the fix conditional and explain the (rare) conditions under
which the problem still occurs.
Also see #747.
Don't just use wxWX2MBbuf which is just a "const char*" in ANSI build and can
become a dangling pointer if the string it was constructed from was temporary,
as it happens with the string returned by wxStyledTextEvent::GetString().
Closes#17517.
When current endpoint is moved to a new position with MoveToPoint() then current sub-path should be ended without closing the figure (no line from the current point to the beginning of the sub-path should be added).
Closes#17516
Differentiate between setting the label from SetLabel() and from
SetPeer() (i.e. initially), because some native controls shouldn't have
an empty string set as their intitial value.
Override SetInitialSize() to be empty for wxNativeWindow in order to
prevent label-setting issues when an unknown, caller-controlled native
widget is attached. Reverts db9baf9aa5,
which was the previous attempt to fix this, but was causing too many
problems elsewhere.
Selection at wxAuiNotebook level was not updated, resulting in all attempts to
select the tab at the same index as the tab that was dragged elsewhere being
ignored, e.g. after dragging the first tab to the second position in the AUI
sample, the first tab couldn't be selected again.
Fix this by always changing the selection in OnTabEndDrag(). This might not be
the best thing to do as the selection is also changed later in the code and
the fact that the code returns without sending the event is probably a bug
too, but for now at least fix the user-visible problem.
Closes#15071.
Apparently it's a common convention to allow width and/or height of a
rectangle to be negative as both GDI and Cairo handle this natively, so also
allow this for GDI+ and document this as the expected behaviour.
Closes#17495.
This solves the same problem as daa8fd03f3 did
for the GTK+ native version and ensures that the variant type at the renderer
level is consistent with the type of the values actually used with this
renderer (which are integers as they are indices).
Closes#17474.
Unlike other platforms, wxMSW assumes natural text directionality (i.e.
right to left under RTL locales), but absolutely filenames are always
LTR because they begin with a Latin character. It is therefore necessary
to add an explicit directional mark in front of them on Windows.
Toplevel windows use their parent's coordinate system as the reference
frame, not desktop's, so need to be adjusted accordingly if its
mirrored. Without these changes, default-positioned wxDialogs would end
to the right side of the parent window's right border (instead of being
slightly inside the window) and changing their size would move them as
well.
This is for the sake of consistency because everywhere else there are used trigonometric functions from standard C library (only <math.h> is included).
When render target to draw to a DC (created with ID2D1Factory::CreateDCRenderTarget method) is bound to the device context with ID2D1DCRenderTarget::BindDC method then the size of the area of drawing has to be a logical size of a DC (with its scaling factor taken int account). This can be determined directly using GetClipBox API and there is no need to pass it as a parameter of wxD2DDCRenderTargetResourceHolder ctor.
Closes#17504.
Determine actual size of wxD2DContext instance and initialize respective data members to report proper size of wxGraphicsContext created by wxGraphicsRenderer::CreateContextFromNativeContext / CreateContextFromNativeWindow.
Closes#17502.
This method can be used to change the list view header appearance.
Add the method declaration, documentation, show it in the sample and implement
it for wxMSW (only, for now).
Add a helper wxMSWImpl::CustomDraw class which will be reused in the other
places too and, for now, use it just to implement support for custom colours
in wxHeaderCtrl.
Notice that the control took care of the custom font on its anyhow and that
background colour is ignored when themes are enabled, so the net effect of
this change is that now changing the header foreground colour works, while
it was ignored before.
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 two existing structs were completely identical, just replace them with a
single wxItemAttr.
Notice that wxDataViewItemAttr is not quite the same, although pretty similar,
so it remains separate for now. It would be nice to combine it with this one
too in the future, e.g. to make it simpler to make items bold in a wxListCtrl.
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.
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.
