We can prepare the escaped code directly here, instead of waiting for
GetWrappedCode() call, this is more clear and safer as it avoids
escaping the code twice accidentally if GetWrappedCode() ends up being
called twice somehow.
While it is allowed there, it is confusing and unnecessary.
Also improve the comment explaining why do we need this output variable
name at all and why does it need to be unique.
This is a non-standard extension in the first place and the variable
name didn't make any sense too, so rename it to be standard-conforming
and actually correspond to what it contains.
There is no need to check that calling MSWSetModernEmulationLevel()
changed the registry key in the test, this is just an implementation
detail of this function.
This makes it unnecessary to define wxIE_EMULATION_LEVEL and
wxREGISTRY_IE_PATH (which are both badly named) in the public header.
Finally, improve the error message in MSWSetModernEmulationLevel() and
add another one for failing to reset the emulation level too.
This helper function runs a JavaScript script and blocks until it
finishes executing, so try to use a name at least hinting at this
instead of being totally generic and useless.
Include wx headers using quotes, not angle brackets.
Wrap over long lines.
Don't put space between the function name and its arguments.
Make wxJSStringRef::ToWxString() itself, not its return value, const.
Improve comments.
Provide native implementation of this function instead of using the ad hoc one
in common code, which didn't really work -- so remove it completely now.
Closes#17189.
Fix comparing items with checkboxes in wxTreeListCtrl and make it
simpler to correctly implement item comparison in other
wxDataViewCtrl-derived classes.
See https://github.com/wxWidgets/wxWidgets/pull/558
When extra style bits are set with the call to
wxPropertyGridManager::SetExtraStyle(), only those which are relevant
to wxPropertyGrid should be passed to the underlying property grid object.
Because it can happen that not all extra style bits of the underlying
wxPropertyGrid have been effectively changed by call to SetExtraStyle()
(e.g. wxPG_EX_NATIVE_DOUBLE_BUFFERING), we have to get the actual style
bits prior to storing them.
When mouse is captured somwhere in the application, it's recommended
to have implemented a EVT_MOUSE_CAPTURE_LOST handler.
Resetting in the handler flag signalling captured state seems
to be a sufficient action because something like this is implemented
in the native Scintilla and it works fine in SciTE.
Closes#17961.
Position of wxProgressDialog cannot be changed directly because the dialog is created in another thread and may exist when SetPosition() is called. New position has be stored in the data structure used to share data between the main thread and the task dialog runner and the real update is done during the cyclic refresh in the dialog thread.
Closes#13546.
Icon for wxProgressDialog cannot be changed directly because the dialog is created in another thread and may not yet exist when SetIcon() is called. We have to store new icon(s) in the data structure used to share data between the main thread and the task dialog runner and wait for a cyclic update.
Closes#17967.
Export this class, which was only used internally by wxTreeListCtrl
before, so that user code can use it for its own columns with custom
wxDataViewCtrl models.
wxGetWinVersion() will return wxWinVersion_Unknown for any MSW version
not recognized by the version of wxWidgets used when building the
application, so it makes sense to use a value higher than all currently
known ones for this constant, so that the checks comparing the result of
wxGetWinVersion() with any known version would still work correctly.
E.g. comparisons like wxGetWinVersion() >= wxWinVersion_Vista will now
continue to work for binaries built using the current wxWidgets even
under some future Windows 11 OS version, unlike before.
The include/wx/msw/private.h header contains a violation of the C++
standards that MSVC tolerates but Clang/LLVM does not.
WinBase.h contains the definition:
#define INVALID_HANDLE_VALUE ((HANDLE)(LONG_PTR)-1)
Which wxWidgets uses in:
template <wxUIntPtr INVALID_VALUE =
(wxUIntPtr)INVALID_HANDLE_VALUE>
The (effective) reinterpret_cast-ing of INVALID_HANDLE_VALUE in
WinBase.h means that the define isn't actually usable as a constant
expression for the template parameter.
Clang has indicated they have no intention of adding an MSVC
compatibility workaround for this problem. See LLVM bug 12116:
https://bugs.llvm.org/show_bug.cgi?id=12116
Given this, rework the wxWidgets header to remove the default
template parameter value (it is not used anywhere).
With this change, it's possible to compile wxWidgets applications
using Clang/LLVM (5.0) under MSVC.
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.
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.
Don't call wxSetlocale() in DoInit() any more, this was redundant when
it was called from Init(wxLanguage) overload.
Add new DoCommonPostInit() called from both Init() overloads after
setting the locale in whichever way they do it to avoid code
duplication.
As a side effect of this change, the error message given if the locale
can't be set is the same now independently of the ctor/Init() overload
used (previously it differed depending on whether a wxLanguage or the
name of the language as string was passed) and it's always logged using
wxLogWarning() and not it in one case and wxLogError() in the other one.
Instead of calling wxLanguageInfo::GetLocaleName(), which called
setlocale() at least thrice (first to query the current locale, second
to try to change it and third to restore the original locale) and then
calling setlocale() again if it succeeded, use the new TrySetLocale()
method which calls setlocale() just once and doesn't require calling it
again in the caller.
This makes the code slightly more efficient but, more importantly,
shorter and more clear.
