This is a helper method used only in wxWidgets itself and only once, so
just inline it at the point of use to avoid exporting an unnecessary
function in the public API.
It doesn't make much sense to require all the graphics backends to
create wxGraphicsPen from either wxPen or wxGraphicsPenInfo when the
former can be handled just once in the common code.
So do just this, leaving CreatePen() overload taking wxGraphicsPenInfo
where the real pen construction takes place and implementing
wxGraphicsPen creation from wxPen in the common wxGraphicsContext code.
This is not 100% backwards-compatible as any code inheriting from
wxGraphicsRenderer and overriding its CreatePen() will now be broken,
however this should be extremely rare (there is no good reason to
inherit from this class in the user code) and result in compile errors
if it does happen.
This is an implementation detail, don't confuse the user with this
template class which isn't supposed to be used in the user code.
Also improve the example in the documentation, the old one (using pen of
width 0 but with a colour) didn't make much sense.
Should work for Caret, still has a problem with the transformation matrix otherwise, too many things have changed there for me to find a quick solutions.
Using popupMenuPositioningItem leads to several problems on modal dialogs - the validation and action callbacks are not used, thefore we revert in this situation to using the older API, see #549 and https://trac.wxwidgets.org/ticket/17459
Prior to 2.9.2, if the focus bitmap was specified but current one wasn't, the focus bitmap was used for hovering as well.
This feature was entirely discarded in b4354db179 (see wxBitmapButton::DoSetBitmap) but it is still described in the documentation of wxButton's states and images. It seems it was removed unintentionally, so let's restore it.
Some current input processing flags, like DLGC_HASSETSEL, should be retained because they are in use (in wxWindowMSW::SetFocusFromKbd() for instance).
Closes#17945.
GetEntitiesParser()->GetCharForCode(NBSP_UNICODE_VALUE) in the non-unicode
build returns the value '?' as it doesn't find a match for that value. The
parser then proceeds to replace all '?' characters in the HTML document with
NBSP.
Change the type of the #define to be unsigned int rather than wxChar for
non-unicode to fix this.
Closes#17692.
Menus on Mac use automatic menu enabling, meaning that the system will enable
menu items only if the app responds to the menu item action. If I understand
correctly, the responder chain for menus in popup dialogs stop at the dialog
window, so the system thinks that the app does not handle the menu items.
This fix should not affect existing code since the wxWidgets user-facing API
dictates that apps specifically disable menu items.
Fix#17459
See Apple docs on automatic menu enabling at
https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/MenuList/Articles/EnablingMenuItems.html#//apple_ref/doc/uid/20000261-BAJBFGED
The latest of those checks tested for w32 API 3.3, which is older than
MinGW 3.4 released which is more than 13 years old, so we can safely
drop them (let alone checks for prehistoric 0.5 w32 API).
This incidentally fixes compilation errors due to the use of
wxCHECK_W32API_VERSION() in wx/msw/winundef.h which was now (since
the changes of 8c572c0a77) included before
this macro was defined.
Also create a wxLocale object with wxLANGUAGE_DEFAULT so that automatic
selection has a better chance of doing the right thing across different
platforms.
If neither wxCAL_SUNDAY_FIRST or wxCAL_MONDAY_FIRST was given, use
wxDateTime::GetFirstWeekDay() to automatically determine the preferred
day.
This changes the earlier default behaviour, which was to use Sunday
if not otherwise specified. However, the wxGTK native calendar control
ignored this behaviour anyway.
This function tries to determine the preferred first day of week to use in
calendars. The procedure for obtaining this information is highly
platform-dependent, and is not possible on all platforms; in that case
Sunday is used as the fallback value.
Implementations are included for MSW, OSX, and Linux.
If the text in the control doesn't end with a new line,
last valid position is just past the last character in the
the last line.
But if it ends with new line, last valid position
is located at the beginning of the next virtual (empty) line.
So, this case has to be also taken into account in determining
whether position is valid or not.
Take into account that last valid position is after the last character of the text.
This applies also to empty controls for which XYToPosition(0, 0) should return 0.
Display "long help" text associated with the toolbar items in the status
bar of the parent frame even if the toolbar is not a direct child of the
frame.
Closes#17897.
