OVERLAPPED struct was allocated using calloc() but deleted later. Fix this by
deallocating it with free() instead.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67806 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Word (16 bits) values were written in the wrong order resulting in invalid GIF files on for example PowerPC machines.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67802 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Move src/msw/hyperlink.cpp and include/wx/msw/hyperlink.h to
ADVANCED_MSW_NATIVE_SRC/HDR from ADVANCED_MSW_SRC/HDR respectively to ensure
that these files are not used in wxUniv build that uses its own, generic,
versions.
This should fix wxUniv/MSW build as the native files didn't even compile with
wxUniv.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67777 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Since r67620 when wxMessageDialog::ShowModal uses a native task dialog and only has an OK button it actually uses a Cancel button, this resulted in the function's return value wrongly changing to wxID_CANCEL. Fix this by handling the special case with only an OK button and return wxID_OK instead of wxID_CANCEL (and thus wxMessageBox, which uses wxMessageDialog::ShowModal, returning wxOK instead of wxCANCEL).
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67771 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Don't use temporary wxChar* variable to store the node string. This is not
only inefficient because we need to convert wxString to it only to convert it
back to wxString on the next line but also breaks compilation when
wxUSE_STD_STRING==1 and wxUSE_STD_CONTAINERS==0 as there is no implicit
conversion between wxString and wxChar* in this case.
Also modify the code for long keys in the same way just for consistency.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67769 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Ensure that the height of the picker control is at least as big as the height
of the associated text control and that it's at least as wide as it is high as
it looks bad otherwise.
Closes#13232.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67763 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Allow passing wxLongLong objects when a "%lld" format specifier (or
equivalent) is used just as we already do for wxString objects when "%s" is
used. This is more convenient and makes wxLongLong closes to the native type.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67760 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
GTK+ may momentarily return invalid date when switching the month in the
calendar control. Check for this and adjust the date ourselves to make it
valid if necessary in order to avoid the asserts from wxDateTime ctor.
Closes#13224.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67759 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use wxWidgets ClientToScreen() function for computing the screen coordinates
of the popup menu instead of Windows ::ClientToScreen() as the latter doesn't
know about the toolbar which may be present in wxFrame and excluded from the
client area.
Closes#13223.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67758 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxMSW could return negative client size for tiny windows with borders, this
was unexpected and shouldn't happen so explicitly ensure it does not.
Also add a unit test to check that this problem doesn't exist in other ports.
Closes#13184.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67754 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Construct the description string from several pieces: the OS name, its build
number and any extra information about it, instead of duplicating the code
appending the build number to the name in several places.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67753 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Previously starting to drag a pane by its gripper worked but once it undocked
it was impossible to drag it by the gripper any more which was annoying for
the user and unexpected.
Fix this by ensuring that we move the correct top level window and not the
child window when dragging floating panes.
Closes#13177.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67751 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The client size of the floating frames ended up being wrong because we changed
the wxRESIZE_BORDER flag after setting it and this changed it (at least under
MSW).
Reset wxRESIZE_BORDER first now and set the client size correctly afterwards.
Closes#13043.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67745 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
If the perspective being loaded contains a maximized pane, set the
m_has_maximized flag to true. Otherwise the flag and the effective pane state
was out of sync resulting in several problems in the UI behaviour.
Closes#12527.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67744 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Fix the condition of the loop in wxAuiToolBar::ToggleTool() to also uncheck
the item with index 0 that was always excluded before because of "i > 0" check
in the loop.
Also exclude the item being turned on itself from the loops, it's useless to
reset its checked state only to turn it on again below.
Closes#11110.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67742 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Check that the AUI pane has a non-NULL associated frame before checking
whether it's shown.
This should fix a crash which could happen when docking an undocked toolbar.
Closes#10926.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67741 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This is especially important for multiple monitor setups in which the old code
could result in false positives and suggest docking a window on a wrong
display.
Closes#10612.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67740 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The cursor wasn't positioned correctly when a floating toolbar was dragged by
pressing the mouse over its gripper because its position didn't take into
account the difference between the client and window coordinates of the
floating window (which is basically the height of the window title bar).
Notice that the same problem still remains when starting to drag a docked
toolbar as it doesn't have the title bar initially but does have it later
so the same fix should probably be applied when we reparent the toolbar.
Closes#9984.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67738 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Don't leave the display and internal variables in inconsistent state when the
mouse capture is lost while a notebook page is being dragged (as can happen
if Alt-Tab is pressed under Windows, for example).
Closes#9976.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67737 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Revert the change of wxUSE_STD_CONTAINERS to 1 by default as this introduces
more incompatibilities which risk hamper upgrading to 3.0 unnecessarily.
Update the documentation to better explain why do the non-standard container
classes exist in wxWidgets and, especially, that they shouldn't be used when
possible. Also document the differences between the normal and STL containers
build in the manual.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67735 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The comment in the function implied that it exchanged the items but in fact it
did not and kept their existing order instead.
Do revert them now, at least like this something visibly happens in the sample
when the items are sorted.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67734 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
As the arguments to the sort function contain the client data associated with
the items, they may be pointers and hence of greater size than long in Win64
builds. Use wxIntPtr instead of long everywhere to fix this.
Notice that this doesn't break compatibility for 32 bit code where long can
still be used as it is the same as wxIntPtr there after the previous commit.
Closes#4309.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67733 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Defining wxIntPtr as ssize_t or long in 32 bit builds doesn't really change
anything but using long means that we can replace longs in the existing API
with wxIntPtr without breaking compatibility, like in wxListCtrl::SortItems().
It is also more compatible with 64 bit builds where wxIntPtr is long already.
So it has some minor advantages and no apparent drawbacks.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67732 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
ScintillaWX.cpp didn't compile because std::string is unknown. Include <string> in case the defines that (by default) are set to wxUSE_STD_DEFAULT are 0.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67730 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
