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
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
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
After fixing the insertion of radio menu items in wxMSW, also do it for wxGTK
to make the newly added unit test pass there as well.
Remove the unneeded wxMenu::m_prevRadio which doesn't make any sense neither
(just as the "current radio group" pointer removed from wxMSW code before) and
simply use the radio group of the existing item this radio item is being
inserted before or after instead.
See #13200.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67721 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Previously the radio menu items could only be appended to a menu in wxMSW,
inserting them (either in an existing radio group or to start a new one) not
only didn't work but could even result in crashes because invalid iterators in
the menu items list could be used.
Fix this by storing the ranges of all radio groups in wxMenu itself instead of
storing the information about the radio group an item belongs to in the item
itself and by updating this data whenever a new radio item is inserted. Also
get rid of the notion of "current radio group" in wxMenu which doesn't really
make any sense.
Finally add a unit test checking that inserting radio items works as expected.
Closes#13200.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67720 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The directories used to be always monitored recursively, even when this wasn't
requested, in wxMSW implementation. Change this but also implement efficient
support for monitoring the entire hierarchies using the native support for
this.
Also update the sample to allow monitoring directories recursively as well.
See #12847.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67693 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
MSW implementation of this class always watched the added entries recursively,
i.e. always behaved as if the entry to watch was added using AddTree().
Fix this simply by not asking ::ReadDirectoryChangesW() to watch the entire
subtree.
See #12847.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67692 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Removing the path watched by wxFileSystemWatcher didn't do anything in wxMSW
implementation so we still continued getting events for the changes to this
path even after calling Remove().
Fix this by really implementing Remove() properly. Also add a unit test
checking that we don't get any events after calling Remove().
See #12847.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67691 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxBitmapButton can be created without a valid bitmap if SetBitmapLabel() is
called later, so don't call SetBitmapLabel() from the constructor if no bitmap
was provided.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67689 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Additionally renamed wxOSX' private wxNativePrinterDC::Ok() function to IsOk().
Didn't deprecate the various Ok() functions: given the amount of changes already introduced in 3.0 a trivial one like this seems more suitable for after 3.0.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67681 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Since the copying of src/osx/carbon/notebmac.cpp to src/osx/notebook_osx.cpp in r55202 the code in wxNotebook::HitTest has been disabled. Enabled it again for at least the Carbon build.
See #13045.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67679 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
When using monolithic build, GUI-specific wxWinModule is still linked in but
its initialization crashes because there is no global display. Simply don't do
anything in this module OnInit() in this case to avoid the problem (which
affected e.g. wxrc in this build configuration).
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67678 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Pass the full path to wxDirExists, not the relative path from the watched
directory as this won't work unless the watched directory is the same as the
current one.
Closes#13161.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67677 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
In r60852 various 'unneeded' SeekI(0) calls were removed. Examined the changes in that revision and restored all SeekI(0) calls after finding out their removal caused problems with reading more than one image from ICO and ANI files. The image handling code for these formats expects to read from the start of a stream for reading its images (as well as for DoCanRead and DoGetImageCount), regardless of the index of the requested image.
Closes#12861.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67671 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxDVC installs temporary event handler that watches for focus changes
and some key events. Make wxSpinCtrlGeneric look like a native
wxControl in this respect even though it's actually a composite control.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67665 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Specifying the size explicitly made wxCOMPILE_TIME_ASSERT() checking that the
array sizes were synchronized useless as the array always had the correct
size, independently of the real number of elements in it.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67645 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
As wxFONTENCODING_{BIG5,SHIFT_JIS,GB2312} are only synonyms for the other
encoding constants, we must append the corresponding names to the array of
names for the real encoding value instead of having the (never used) separate
entries for them in the names array.
Closes#13164.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67644 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The problem alluded to by the commit message of r40658 arose only in the DLL
build using VC6 so reintroduce the workaround for it removed by r67634 but
make it VC6-specific and, arguably even more importantly, also make it work
correctly for wxULongLongNative values greater than LONGLONG_MAX.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67643 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Notice that this commit doesn't really change anything, in particular it
doesn't correct zooming for zoom factors that are power of 2 (which was broken
before as ticket #11669 showed), this was already done by the previous commit.
This one simply makes multiplying by VIEWPORT_EXTENT a tiny bit more efficient.
See #9554.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67624 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Multiply by scale factor when it's > 1 and divide by it when it's < 1 to avoid
rounding errors. By choosing whether to increase the viewport or window
extents we increase precisions without any apparent negative effects (at least
under Windows NT where the coordinates in 2^27 range are supported, but even
under Windows 9x it's not clear if the old code was better as while we never
overflowed the viewport extents, we could overflow the window ones easily for
small zoom factors).
Closes#9554.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67623 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
We didn't draw the last line and row of the image for some reason, simply
remove the -1 which prevented us from doing this.
Closes#12476.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67622 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The native task dialog doesn't allow using Escape (nor Alt-F4 but this is less
annoying) to close it unless it has a Cancel button, so by default the dialogs
with only "OK" couldn't be closed with Escape.
Work around this by creating a Cancel button with "OK" label instead. This is
not ideal but there doesn't seem to be any other way to make this work.
See #12501.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67620 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Still show the print preview app modally by default, i.e. disabling all the
other windows, but also allow disabling only the preview parent or nothing at
all.
Closes#13108.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67619 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
