In 64 bit build, size_t can be 64 bits while %i expects a 32 bit value.
Fix this by just avoiding the unnecessary use of size_t, the number of entries
in the index is not going to be greater than 2^32.
Closes#16163.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@76285 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
NSUInteger is unsigned long in 64 bit builds, but unsigned int in 32 bits, so
case it to long explicitly to avoid warnings about using it with %lu format
specifier.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@76284 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Eliminates many "Gtk-WARNING **: Unknown paper size", and the occasional
"GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed".
And fixes approximately one zillion memory leaks.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@76270 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Apply the same workaround as was applied in r67771 to wxMessageDialog to
wxRichMessageDialog and map IDCANCEL returned from it to IDOK if "Cancel" is
the only button in the dialog -- as in this case it's really just a renamed
(for convenience of allowing the user to use "Esc" to close it) "OK".
Closes#16153.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@76254 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This fix is similar to the previous commit but more speculative, as we
currently don't have a bug scenario for it. Still, it seems to be wrong to
call PrepareForItem() just before GetLineStart() which undoes its effect, so
exchange the order of the calls.
See #16132.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@76213 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
OS X 10.9 (possibly earlier) don't have nil contentView in NSSavePanel
anymore, a NSRemoteView instance is used. The wx code that follows this
test still crashes under sandbox, though, so update the check to use the
APP_SANDBOX_CONTAINER_ID environment variable, which is only set when
running under the sandbox.
This is just another quick fix for the existing uncomfortably long-lived
sandbox crash hotfix, not a proper solution.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@76208 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Native text control sends EN_CHANGE when the font changes, producing a
wxEVT_TEXT event as if the user changed the value. This is not the case,
so supress the event.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@76207 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Don't leave the handles of all threads used for monitoring the child processes
open until the main process termination, rather close them as soon as the
monitored process terminates.
This ensures that we don't accumulate potentially unbounded number of open
handles if we keep launching new child processes. An even better idea would be
to actually use a single thread for monitoring all of them, but this fix is
much simpler and should fix the most acute problem for now.
Closes#16123.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@76199 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The changes of r75936 didn't work correctly if the handler of wxEVT_TEXT in
some text control modified a (potentially) different text control, as the same
global variable was reused with disastrous results. Avoid this by keeping a
stack of insertion lengths instead.
Additionally, fix another problem in r75936 which used 0 as a special marker
for the insertion length, which result in redoing each insertion of empty
string (which is another word for Remove()) twice unnecessarily, by using -1
instead.
Closes#15980.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@76194 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The toolbar was in an inconsistent state when recalculating the sizes of the
separators used as placeholders for the controls and stretch spacers as the
tool was already deleted from the native toolbar but still present in wx
internal toolbar data and this resulted in discrepancies between the indices
in the native and wx toolbars.
Fix this by specially marking the already deleted but not yet removed tool and
ignoring it during the recalculations.
This makes the old, and only partially successful, attempt to work around this
bug in DoDeleteTool() unnecessary and so the code is actually simplified by
this change.
Closes#16095.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@76183 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
We need to call DoRemove() on all watcher objects to really remove them, just
removing our record of them was not enough and e.g. resulted in errors if we
tried to re-add a previously watched path again.
Closes#15531.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@76182 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Don't log an incomprehensible error when the watched directory itself is
deleted, but generate wxFSW_EVENT_DELETE for it. This is consistent with the
behaviour under Unix and generally more useful.
Closes#13294.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@76181 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Make wxIOCPService::GetStatus() smarter about its return value, it makes sense
to encapsulate the convention used to indicate the thread exit condition
inside wxIOCPService class itself instead of sharing it between it
wxIOCPThread itself.
It will also make it easier to detect more detailed error conditions in this
code.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@76180 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
For some reason the border was used only on the left side but not on the right
one, resulting in the ugly looking label flush to the right dialog border if
it was long enough.
Closes#16094.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@76155 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
r76141 fixed the resource leak when wxStaticBitmap image was replaced by
another one but the leak still happened at the end, when the wxStaticBitmap
was destroyed.
Fix it there as well in the same way.
Closes#16068.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@76145 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
ICO files can contain data in PNG, as well as BMP, format in recent (i.e. from
this millennium) versions of Windows, so check for this case in wxICOHandler
and load such data using wxPNGHandler.
See #15918.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@76127 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The width was calculated incorrectly in this case as we simply multiplied the
width of the widest column by their number in this case, but actually each of
them has its own width which needs to be calculated separately.
See #13579.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@76106 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The item rectangle used wrong vertical coordinates which didn't matter (much?)
for the single row toolbars but was completely wrong for toolbars with more
than one row.
Don't always anchor the rectangle at the window top to avoid this.
See #13579.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@76105 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Stretchable separators simply don't work correctly when the space they are
supposed to stretch onto is distributed across several different toolbar rows
or columns, so just disable them for multi-row (or column, for vertical
toolbars) case.
See #13579.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@76104 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
