Add wxMessageOutputWithConv mix-in class to avoid duplicating the same
code in wxLogStream and wxMessageOutputStderr.
Also derive wxLogStderr from wxMessageOutputStderr to reuse its code
without having to create a temporary object of this type (which will be
more expensive now that doing it involves creating a heap-allocated
conversion object copy).
Check for web extension in ".." and "../.." to find it when running the
webview test and sample, respectively, even if "make install" hadn't
been done yet.
Also give a warning about the missing extension if we can't find it
anywhere.
While it is not guaranteed in general that destroying a window from an
event handler for an event originating from this window itself works, it
did use to work in the case of wxToolBar and its event handlers. However
this stopped working since faffaaae29 as
it added a test using the now deleted object member fields after the
call to the event handler.
To fix this regression without reintroducing the bug fixed by that
commit (see #16762), add an ugly way to check if the toolbar is still
alive after a call to its event handler and do it explicitly after
OnLeftClick() returns.
Closes#17732.
This commit refactors the overloads of cMB2WC() and cWC2MB() methods
taking raw pointers and buffers to reuse the same code and fixes the
wrong length of the buffer returned by cWC2MB(wchar_t*) overload for
conversions using multiple bytes to represent the NUL terminator
character (it previously was wrong for UTF-16 and UTF-32 conversions due
to wrongly subtracting 1 from the length when creating it instead of
correctly subtracting GetMBNulLen()) and the wrong length of the buffer
returned from cMB2WC(char*) overload where no adjustment for the
trailing NUL was done at all.
Also return simple default-constructed buffers from these methods in
case of failure instead of using wxScopedCharBuffer::CreateNonOwned()
which is less obvious and less efficient (even if the latter probably
doesn't matter here because it's only done in case of an error).
Finally, add tests checking that using WC2MB() or either of cWC2MB()
overloads returns the buffers of the same length and with the same
contents.
The wxGTK implementation uses wx{File,Dir}Button, which derives from
wxButton, but is not a GtkButton, so many operations which try to modify
it, such as changing it's style, are likely to result in errors.
See #17984
We can only use utf8_length() if the conversion used with this object
uses UTF-8 too, otherwise we still need to do the conversion to find out
how many bytes does the string content take in the given encoding.
See #17985.
The Darwin linking problem mentioned in the comment doesn't exist in any
of the still supported macOS versions, so it doesn't make sense to
continue working around it.
Initialize m_pos correctly when using an existing, and hence possibly
not empty, string (and not the internal one which is always empty
initially). The old code was totally wrong as it divided the string
length by the size of wxChar instead of multiplying by it, but doing
this could have been wrong too with UTF-16 and surrogates, so use the
conversion object to compute the real length of the string
representation in the corresponding encoding.
Add a simple unit test checking that this works as intended.
Closes#17985.
Because top windows can (and do) act as parents for certain dialogs, a
window already pending delete shouldn't be explicitly reported as the top
window because all dialogs which would use it as a parent
would be destroyed at nearest idle cycle.
Closes#17982.
Check for the record size before subtracting it from the end position:
the former must be smaller than the latter for all valid ZIP files and
not performing this check could result in an integer overflow error from
the undefined behaviour sanitizer for bad input.
Credit to OSS-Fuzz: this solves its issue 3828.
Zip filenames containing non ASCII characters will be marked with
bit 11 in the general purpose flags and will use UTF-8 encoding.
By only setting the flag when non ASCII characters are used the
created archives should be binary identical to previous versions.
The old behavior can be achieved by explicitly using wxConvLocal
with the constructor. This should also ensure that
existing code using a custom wxMBConv should work as before.
This shouldn't be needed any more, after the previous commit which
replaces the raw pointer to the focused child in wxTopLevelWindowMSW
with a safe weak reference.
If the window stored as m_winLastFocused in one TLW was reparented to
another one and then destroyed, this pointer to it wasn't updated and
became dangling.
Fix this by using a safe weak reference instead of raw pointer for
m_winLastFocused. This ensures that it can never be used when it becomes
invalid.
Closes#17980.
Skip memcpy() call if its source and destination would overlap: this is
not allowed and is correctly flagged as an error by address sanitizer
and is unnecessary anyhow as we're certainly not going to find the magic
value in fewer than 3 remaining bytes.
Credit to OSS-Fuzz: this solves its issue 3794.
This was somehow removed by af8f7f33c3 but
is needed: implicit conversion uses the current locale encoding, which
is often, but _not_ always, UTF-8, while we always need to use UTF-8
with WebKit functions.
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.
Don't use wrong types and then cast the function pointer to the right
type, but just use the correct type from the beginning.
Also make the callback extern "C", as it should be, to be called from C
code.
Errors were reported in different ways (including not being reported at
all in wxMSW) in different ports. Try to consistently do it in the same
way now and use exactly the same sentences to facilitate translators
life.
Using pointer here makes no sense: this parameter can never be null and
we don't even have the excuse of making it simpler to call like this as
the caller has an object and not a pointer to it, so this even results
in extra typing.
This function was used only once and didn't really help understanding
the code and just required extra casts when passing arguments to it, for
some reason.
Just merge it into RunScriptSync() itself.
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.
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
This allows to hide the long (and possibly not fitting on the screen)
call stack by default to avoid intimidating people not used to it and
provides a much more clear way to ignore the subsequent asserts, by
clicking a dedicated checkbox instead of having to choose the "Cancel"
button which didn't make much sense.
See #15430.
This makes more sense than the default default (sic) "Yes" button,
pressing which accidentally could kill the program if not running under
the debugger.
This should have been part of 55fd62c1e3
which only updated the default assert handler, but not the one used by
default in all GUI applications, for some reason, see there for more
explanations.
Do this now to ensure that after pressing "Yes" in the assert failure
dialog, the debugger opens at the assert location and not deep inside
wxWidgets code.
See #11184.
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.
WM_CONTEXTMENU message is generated directly by the system when the user presses and releases the VK_APPS key so there is no need to do this by emulating right mouse button click.
Closes#17969.
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.
At least under wxMSW and wxGTK opening a popup menu when mouse is captured
generates EVT_MOUSE_CAPTURE_LOST. We would like to avoid this and
to release capture in a controlled way.
See #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.
In wxProgressDialog::SetTitle(), wxSPDD_TITLE_CHANGED flag signaling a request to update a title should be added to the flags already being set and signaling another data waiting for the update.
Closes#17966.
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.
wxBitmap should be made transparency-capable before copying wxIcon bits to it. Doing so when wxIcon bits are already copied seems to work fine for OSX 10.8, but not for newer versions.
Closes#17953.
Do compile wxEntry(void) overload used in wxIMPLEMENT_WXWIN_MAIN_CONSOLE
expansion by non-MSVC compilers under MSW inside the monolithic library
too by replacing the "#if !wxUSE_GUI" check guarding it with "#if
wxUSE_BASE" one.
It's not really clear how could this have ever worked without this fix
before, although it apparently did, but stopped with gcc 7.
Override DoCompareValues() to handle values of "wxDataViewCheckIconText"
type which is not handled by wxDataViewModel::Compare() itself.
This ensures that the items with checkboxes are sorted by their (text)
contents instead of by the order of their addresses in memory as was
done for them, as for any unknown values type, previously.
At least in wxMSW wxPen::GetStipple() returns a non-null (but invalid)
bitmap even when pen style is not wxPENSTYLE_STIPPLE, so don't test for
this bitmap when creating a wxGraphicsPen from a wxPen but for the style
directly.
This avoids using this invalid bitmap later in D2D code, where it
resulted in assert failures.
Also add a similar style test before calling wxPen::GetDashes() for
consistency, even if it doesn't seem to be strictly necessary.
See https://github.com/wxWidgets/wxWidgets/pull/553Closes#17958.
When replacing m_OutlineView with a new one in ClearColumns(), we must
explicitly remove the old one from its superview to ensure that no more
drawing operations are pending for it. Without this change, Cocoa
drawing code would occasionally crash on attempting to message the
now-zombie m_OutlineView instance. This happened in older macOS
versions too, but became much more frequent in 10.13 High Sierra.
To determine which wxSpinButton arrow was clicked, in the action handler there is compared current NSStepper value (after the actual change) with the value before the change. This former value is fetched in the internal mouse click event handler which is invoked before the action handler. This method of determining a delta works fine as long as the current value remains unchanged between the execution of the internal mouse click event handler and the action handler. But if the current value is explicitly changed (by calls to SetValue(), SetRange()) in some handler(s) invoked between these two (like e.g. bound EVT_LEFT_DOWN handler), calculated delta can be invalid and therefore wrong EVT_SPIN_DOWN/UP events can be sent.
To get correct delta value we should to keep track of all explicit changes made to the current value starting from the mouse click and up to the entry to the action handler.
Closes#17955.
SetSelections was clearing the previous selection, invalidating the
current item, but didn't set it after selecting the new items.
This was causing issues in keyboard selection, e.g. pressing Shift+click
didn't select all the items between the selected and the clicked ones.
Fix this by making the last item of the new selection current, which is
the expected behaviour considering that SetSelections() should be
equivalent to calling SetSelection() with all items one by one.
Signed-off-by: Anil Kumar <anilkumar8753@gmail.com>
Closes https://github.com/wxWidgets/wxWidgets/pull/557
Using smart array class is better than using ad hoc scope guards for
freeing memory in any case, but in this particular case it also helps to
avoid g++ 7 -Wnoexcept-type warnings due to type of free() changing to
become "void(*)() noexcept" in C++17.
Starting with version 3.5, Scintilla implemented a newer method for
handling timers and used this method in its Windows, GTK+, Cocoa, and Qt
ports. This patch attempts to bring the timer handling for wxSTC in line
with those other ports.
Closes#17949.
Don't refresh the control unnecessarily after inserting the first child
node when using modern (i.e. post-XP) MSW version, this just slows down
inserting of the first child item in big trees.
Closes https://github.com/wxWidgets/wxWidgets/pull/555
This replaces the changes of 24c0401e81
which, for some reason, used a global variable for storing whether the
selection function had been already set or not, when this clearly is a
per-control (or per-selection, but this seems one and the same) bit of
information.
Replace global ms_firstTime with a wxDataViewCtrlInternal field to avoid
asserts as soon as EditItem() is called on more than one wxDataViewCtrl.
Closes#17946.
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.
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.
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.
New line is not always marked by 2-character (\r\n) sequence. It can be
also 1-character (\r) for RichText controls or even no mark at all (for
wrapped line).
This reverts commit c4e1fb4ef9.
Last position is not necessarily the number of characters in the buffer,
rich edit controls still store the text using CR LF between lines, but
GetLastPosition() should return the position as if they used only LF to
be consistent with all the other positions in these controls and
changing this broke existing code passing GetLastPosition() to other
functions taking position.
There is a valid position after the last character of the text in
wxTextCtrl, e.g. position 0 in the empty control, so account for it and,
notably, don't return -1 from XYToPosition(0, 0) when the control is
empty.
This fixes a regression in a69ab2907c.
Use wxScopedCharBuffer as we only need the buffer in the current scope.
This avoids a buffer copy done by wxCharBuffer which could be a
significant pessimization for large buffers.
Also don't call strlen() unnecessarily, we already know the buffer
length, so just use it.