Support auto-scrolling both orientations simultaneously and make
auto-scroll region configurable.
Also allow changing auto-scroll dir without ending drag operation and
starting another one.
Closes#25978.
Make the code work on all platforms by adding SetOpacity(-1) call needed
under wxMSW to enable overlay transparency and using wxGCDC to take into
account the brush transparency.
A clip region set using SetDeviceClippingRegion() on a DC should not scroll
when the canvas we are drawing on scrolls. The drawing sample behaves like
this if the DC is a wxDC instance but not if it is a wxGC instance (because
it is not properly prepared when the canvas is scrolled, i.e.: GetDeviceOrigin()
always returns (0, 0) for a wxGC). So this bug should be fixed by preparing
the correct DC that we are actually using for drawing.
Closes#25877.
First render to a temporary wxSVGFileDC, then use the size of the bounding box as input for the actual SVG size.
Use a slightly larger size to account for lines drawn with a bigger wxPen width.
Remove wrong FromPhys() call, wxSYS_CURSOR_Y is expressed in logical
pixels, this is a leftover from an old and never used version of the
code in which it was wrongly expressed in physical ones.
This new class allows to let wxWidgets select the appropriate cursor,
similarly to how wxBitmapBundle allows to select the bitmap of the
appropriate size.
Document the new class and show using it in the drawing sample.
There doesn't seem to be any sample more suitable than this one, so add
a "Cursors" screen to it, as we already have "Colours" screens there.
For now just show the cursor size.
Allow reverting to using the traditional values for the conflicting
colours by calling UseScheme(Traditional) if really needed.
This is another attempt for changing wxColourDatabase to use more
standard colour values, after the previous attempt in bb131fdbc5
(updated colour definitions to the new official X version (patch
771272), 2003-07-17) which was reverted almost immediately after in
5e2ab1ea5d (reverted the last change (colour values changes), it cerated
too many problems, 2003-07-19), see #6031. Unlike the previous ones, it
provides an escape hatch in the form of UseScheme() and also leaves
traditional wx colour names not clashing with CSS ones still available.
Also update the "drawing" sample to allow showing both colour schemes,
and extend its view port to fit all the colour names vertically.
See #23518.
X11/X.h #defines Success as 0, resulting in compilation errors due to a
name clash if this header happens to be included before wx/app.h.
We could #undef Success here, but it seems better to avoid the problem
by just renaming our constant, which was introduced only recently and so
shouldn't be used in many places yet.
See #24633.
Allow the application to override the default system mode and,
incidentally, also to provide a more portable way of enabling dark mode
under MSW.
Show how to use the new function in the drawing sample.
Closes#19185.
Closes#23867.
Having this line is not useful at all as it doesn't contain any
information and shouldn't be filled in the future as git-shortlog can
provide the information about people who changed the given file more
more reliably than consulting the comments in any case.
Keep the non-blank lines for historical purposes.
Reset the selection and avoid the assert which happened when the capture
was lost unexpectedly (e.g. due to switching to another window using
some key combination without releasing the mouse).
wxOSX already does it, so do it in wxMSW too for consistency and because
it seems useful to be able to react to the same event in all cases.
Update the drawing sample to refresh its system colours scheme whenever
the theme is changed.
This allows to determine if dark mode is enabled (for the applications
and/or the system UI itself, respectively) system-wide which is useful
now that IsDark() returns false unless MSWEnableDarkMode() is called.
Also document the incompatible change to IsDark().
Adjust scrolled contents for screen drawing directly in EVT_PAINT
handler instead of doing so conditionally for generic wxDC.
This also helps demonstrating if wxPaintDC transformations
are transferred properly to wxGCDC.
This is a combination of running clang-tidy with modernize-use-nullptr
check for some ports (GTK, X11, OSX) and manual changes to the ports for
which it couldn't be used easily (MSW, DFB) and also manually updating
the docs.
Also replace NULL with null or nullptr in the comments as this is more
consistent with the use of nullptr in the code and makes it simpler to
grep for the remaining occurrences of NULL itself.
And also use null in the assert messages.
Only a few occurrences of "NULL" are still left in non-C files, mostly
corresponding to unclear comments or string output which it might not be
safe to change.
This port hasn't been updated for ages and is not used by anybody any
longer, so remove its code to facilitate maintenance.
Also remove references to this port from the documentation and most of
the other places (VMS-specific descrip.vms files still check for it
because it's not clear how to update them all), including configure.
Regenerate the latter and rebake all makefiles.
Finally document that this port is not available any longer.
Don't use FromDIP for 0.
Include DIP in drawing sample variable and function names to make it clear these sizes are in DIP.
Show both logical and DIP coordinates in statusbar.
wxBitmap::CreateWithDIPSize expects an DPI independent size.
And when saving as SVG, it also expects a DPI independent size.
Also show DPI independent coordinates in the status bar.
This reverts most of the changes from ee2b02614e (Add GetDPIScaleFactor to wxDC
and wxGraphicsContext, 2022-04-16).
This is not supposed to be used to scale pixels, FromDIP will be added instead.
Temporary use scale=1 in the drawing sample until FromDIP is added.
Apply it manually because MSW doesn't do it automatically for us and
also adjust the font size in wxMemoryDC as the base class version only
does it for the device contexts associated with a window, but we also
need to do it when using a wxMemoryDC for a bitmap using scale factor
different from that of the main display.
As the result of these changes, contents drawn on wxMemoryDC, both
directly via its own methods, or via wxGraphicsContext (using either
GDI+ or Direct2D) created from it, it appears the same as in wxWindowDC
(e.g. wxPaintDC) created for a window using the same scale.
Closes#22130.
Closes#22234.
Remove support for Borland C++ compiler, it wasn't tested since a long
time and probably didn't work anyhow and there was no interest in
keeping support for it since many years.
See https://github.com/wxWidgets/wxWidgets/pull/2087
This has the disadvantage of not using the same accelerators in
different wxWidgets builds, but the advantage of appearing logical to a
casual user when running the sample, while having "0, 1, 3, 4" sequence
was surprising.
Alternatively, we could always add all menu items, but disable the ones
that are not available in the current build. It could be surprising to
see "GDI+" under non-MSW systems too though.
Make "Use default wxGraphicsContext" part of the renderer selection
radio group and put it in correct order, as having "1, 0, 3, 4"
accelerators order in the menu was really surprising.
Remove wxEVT_UPDATE_UI handlers as they complicated things in the sample
code (which is supposed to be simple, after all) without much benefit
and arguably even added to the confusion during run-time as menu items
could both be manually selected and checked automatically.
This adds a demonstration of drawing with affine 2D transformation applied
to wxDC. Transformation paramaters (translation, scale, rotation angle)
can be set/reset with new menu "Transformation".
Bill Su
Daniel Collins
Robert Roebling
Vadim Zeitlin
Maarten Bent
ali kettab
Stefan Csomor
Paul Cornett
Artur Wieczorek
PB
Kenneth Porter
Artur Wieczorek