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.
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.
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.
This method seems completely unnecessary, the base
wxTextEntry::DoSetValue(), which delegates to Remove() and WriteText(),
seems to work just as well and avoids code duplication between this
method and wxTextCtrl::WriteText().
Notice that gtk_text_buffer_set_text() is just a trivial wrapper around
gtk_text_buffer_delete() and gtk_text_buffer_insert() anyhow, so there
is no efficiency loss in not using it neither.
Fix compilation/link problems due to symbols redefinitions in user code
that could happen if it included some wx header first, then <windows.h>
(possibly indirectly, e.g. via another third party library) and then
another wx header -- in this case, the second wx header wasn't protected
from <windows.h> redefinitions resulting in all the usual problems.
Avoid this by always including winundef.h whenever any wx header is
included, not just when wx/defs.h is included for the first time.
Get rid of ugly wxDynamicCastThis()s in wxMSW wxControl code and add a
new virtual method overridden in wx{Tree,List}Ctrl instead.
Also stop comparing the font with wxSYS_DEFAULT_GUI_FONT, there doesn't
seem to be any good reason to set this particular font for these
controls neither.
In addition to simplifying and de-ugligying the code, this commit
incidentally fixes -Wnonnull-compare warnings in this code from gcc6
too.
Under MSW calling UnblockAndRegisterWithEventLoop() for blocking sockets
is not only useless, but actually harmful when the socket is used from a
worker thread (which is the common case for blocking sockets), as it
means that the main thread will be receiving notifications for the
socket events and modifying the socket object while it's being used from
the other thread, resulting in data races and general brokenness.
This is similar to e18c8fd29a for Unix
sockets.
Closes#17937.
When WM_ENDSESSION was received by the application, the wxApp object
itself was shut down by calling OnExit() on it before all the TLWs were
destroyed, which could be completely unexpected as during normal
shutdown the order of events is exactly the reverse.
In practice, this resulted in crashes in any application whose main
window close event handler or dtor touched wxTheApp in any way (e.g. to
save any configuration in the global wxConfig object destroyed by
wxApp::OnExit()).
See #9590 (sorry for missing the point before, ATS).
Rewrote wxOSX radio groups-related code reusing the code which works on
wxMSW and which seems to provide more rich functionality (supports adding
radio as well as no-radio items) and to have known bugs fixed.
The ranges of all radio groups are stored in wxMenu itself instead of
storing the information about the radio group an item belongs to in
the item itself - see 89511b4268.
Closes#14213.
Closes#17568.
Apparently various text wrapping modes are not supported natively by
NSTextView (apart from word wrapping which is used by default) and
non-default wrapping has to be implemented in the custom code.
To wrap lines at any character, NSLineBreakByCharWrapping style should be
applied at any text change to the entire text stored in NSTextStorage
associated with NSTextView. This is done in DoUpdateTextStyle() method
which is called from controlTextDidChange() when text is modified by
the user, or SetStringValue() and WriteText() when text is set
programmatically.
This virtual method is implemented in wxWindowBase class only when
wxUSE_DRAG_AND_DROP==1, so it should be re-implemented in the derived class
wxWindowMac also only when wxUSE_DRAG_AND_DROP==1.
wxScopedPtr is referred in wxSVGFileDCImpl declaration, but corresponding
header file is not explicitly included. This can break the compilation if
wxScopedPtr declaration is not included by chance by another module (e.g.
is taken from translation.h but it is not effective when wxUSE_INTL==0).
MakeConfigFileName() is declared as a pure virtual function in the base
class wxStandardPathsBase and has to be implemented in the derived class
wxStandardPaths.
This fixes compilation when wxUSE_STDPATHS==0.
Several functions of wxTextEntry and wxTextCtrl call to
gtk_entry_get_text_length() API to determine the length of the text in
GTKEntry. This API is available since GTK+ 2.14 so we have to implement
a fallback method for older GTK+ versions.
Dedicated function GTKGetEntryTextLength() is implemented in wxTextEntry
and exposed through its interface because it is also used in wxTextCtrl.
Apparently there is no native API to retrieve such information in a simple
way so all calculations have to be done with raw text stored in
the corresponding control(s).
Closes#4146.
See #17811.
The old API didn't make any sense for the most common case when both the
user name and password need to be stored, as it required providing the
user name as input, which couldn't work (but somehow this went
unnoticed for more than a year...).
Fix this by returning the username, and not only the password, from
Load() instead of taking it as parameter and removing this parameter
from Delete() as well.
Also improve the documentation, notably include a simple example of
using this class.
Notice that this is a backwards-incompatible change, but the old API was
really badly broken and didn't appear in 3.1.0 yet, so the breakage is
both unavoidable and, hopefully, shouldn't affect much code.
Nevertheless, a special wxHAS_SECRETSTORE_LOAD_USERNAME symbol is added
to allow testing for it if necessary.
When there is open an editor for some property and in the same time
wxPropertyGrid layout is changed (due to the adding or removing a property,
sorting), it is necessary to recalculate the actual position of the active
editor to display it in the cell dedicated for the edited property. Under
some platforms the position of the edit control is shifted within the cell
and we have to take this shift into account in repositioning process.
Because actual value of the shift depends on the platform and on
the particular control, it is convenient to determine actual shift when
the editor is created and use this value whenever repositioning is done.
Close#17912.
Position of the editor associated with properties like StringProperty,
IntProperty, etc. needs to be adjusted in order to display edited text
at the same position as the text which is displayed as a property value
prior to the editing.
Position of the editor associated with properties like StringProperty,
IntProperty, etc. needs to be adjusted in order to display edited text
string at the same position as the text which is displayed as a property
value prior to the editing.
Don't try to write a general purpose class, but provide just the methods
that we need in our code.
This fixes the bug added in 294436c8bb
which resulted in a crash because a literal string, not a BSTR, was
passed to wxBasicString ctor.
