Make scrolling upwards (positive delta) go to the past (i.e. decrease the
date) for consistency with the native calendar controls.
See 50daf1feab (commitcomment-13087042)
Mimics the scrolling behaviour of native MSW and GTK calendars by allowing to
increment/decrement the month by scrolling anywhere on the generic calendar.
Additionally, use horizontal scrolling to increment/decrement the year.
Closes https://github.com/wxWidgets/wxWidgets/pull/88
Allow to disable maximize and minimize buttons dynamically just as we already
allow to disable the "Close" button using EnableCloseButton().
Currently implemented for MSW and OSX only.
Closes#17133.
Unexpectedly, minimizing the window by clicking on its taskbar icon resulted
in a wxActivateEvent. This broke the focus handling in wxTLW and resulted in
debug messages about ::SetFocus() failure whenever the window was minimized in
this way.
It also seems that other existing code doesn't take into account the
possibility of getting an "active" activation event when the window is
minimized and this doesn't happen in the other ports, so don't send this event
in wxMSW neither.
Closes#17128.
Deleting a tool from its own event handler resulted in at least in an assert
and could also lead to a crash as an already deallocated pointer was
dereferenced.
Fix this by checking if the tool with the same ID is still available after the
event handler finishes.
See #16762.
On OS X (tested on 10.10.5) calls to window.open() with a different target
than _self were simply ignored. No navigation and no EVT_WEBVIEW_NEWWINDOW as
expected.
Unfortunately WebKit does not call the decidePolicyForNewWindowAction delegate
method in these cases. A new delegate method createWebViewWithRequest has been
implemented to handle this case and send EVT_WEBVIEW_NEWWINDOW as in other
ports.
Closes https://github.com/wxWidgets/wxWidgets/pull/85
wxOSX and wxGTK previously used their own methods for handling the enabled
state and the attributes of the items being rendered, change them to reuse the
same methods as the generic implementation, i.e. SetEnabled() and SetAttr()
and remove the port-specific GtkSetAttr(), OSXApplyAttr() and so on.
This has the advantage of ensuring that the logic is the same for all
platforms (e.g. item enabled status wasn't handled in the same way in wxGTK as
in the other ports previously) and hopefully makes the code simpler by cutting
down on the number of virtual methods.
Notice that GtkSupportsAttrs() optimization was removed as it didn't seem to
be worth the bother (we basically saved a call to a virtual model method at a
price of a virtual renderer method call) and preserving it would have
complicated things needlessly.
Because on some ports native renderers require a valid reference to the windows be drawn then it is necessary to implement and use new wxPGCellRenderer::DrawCaptionSelectionRect method which passes this additional argument.
Move the checks for the type mismatch between the type of the value returned
by wxDataViewModel and the type expected by wxDataViewRenderer into common
code. This avoids duplicating the same code in wxGTK and wxOSX and, more
importantly, means that this check is also performed in wxMSW when using the
generic version, so that the problems such as the one fixed in 3ff8c3c ("add
missing wxDataViewDateRenderer::GetDefaultType()") would be visible there too.
SetPropertyTextColour, SetPropertyBackgroundColour methods are able to set colours recursively for sub-properties but SetPropertyColoursToDefault method is not.
For the sake of consistency, SetPropertyColoursToDefault method is extended to have the same capabilities as SetPropertyTextColour and SetPropertyBackgroundColour. Behaviour and signature in default case (no recursion) is preserved.
For internal purposes there were also implemented helper methods in wxPGProperty class: SetDefaultColours, ClearCells.
This was disabled by 262ed2c133 but doesn't seem
to be justified, we shouldn't be overriding native platform behaviour without a
very good reason and there doesn't seem to be any.
See #16805.
The comment is (probably) still relevant, otherwise we wouldn't need this code
at all but could just disable the control normally. It was probably removed
because of a mix up between "disabling the control" and "settings its colour
to disabled".
See #10254.
Extract extra data from buffer allocated for the local extra field.
This fixes regression after ZIP-64 additions which resulted in crashes while
running the test suite.
Closes https://github.com/wxWidgets/wxWidgets/pull/78
For some reason the implementation of this method (see #12754) also put the
image on the clipboard, which was completely unexpected and unnecessary, so
just don't do it.
Closes https://github.com/wxWidgets/wxWidgets/pull/77
Use the marketing/code name of the current OS X version (if known) as part of the wxGetOsDescription(). Also removed the Mac prefix in the description which is no longer used since OS X 10.8.
Some native controls don't take kindly to being set setStringValue: with
a value invalid for the control (such as empty string for
NSPathControl). Don't do this if the label is empty anyway to avoid
problems with wxNativeWindow when the underlying native control is like
that.
Calling wxDataOutputStream::Write64() with a wxFileOffset argument is
ambiguous as wxFileOffset is neither wxInt64 nor wxUint64, so cast it to one
of them (it doesn't matter which) explicitly.
Zip archives with sizes larger 4GB or containing files larger than 4GB or more
than 65k files are saved in ZIP64 format which adds a few additional footers
and extra fields to allow to exceed these limits.
This implements the PKWARE specification available at:
https://www.pkware.com/support/zip-app-note
It has been tested for compatibility with Windows internal ZIP folders, OSX
Archive Utility and 7-zip.
Closes https://github.com/wxWidgets/wxWidgets/pull/72
When wxBitmapComboBox::DoInsertItems() is called from
wxBitmapComboBox::RecreateControl() then the existing bitmap array should be
reused and new bitmaps shouldn't be allocated.
Closes https://github.com/wxWidgets/wxWidgets/pull/71
When wxBitmapComboBox::DoInsertItems() is called and wxCB_SORT flag is set then
due to the sorting the position of the every element in the final item list
can be different than in the input table. To ensure consistency between item
list and bitmap array all new items should be added one by one. Based on the
actual index of every added item the bitmap array should be arranged
accordingly.
Closes#16627.
See https://github.com/wxWidgets/wxWidgets/pull/71
