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.
Added messages to show that Copy tool intentionally influences Print tool and
Cut tool influences Help tool, as this is rather unexpected behaviour and
could be seen as a bug.
This ensures that the messages always appear in the correct order, even if the
user clicked somewhere in the middle of the control -- which would previously
result in inserting the next message at the cursor position, not the end.
Ensure that the count of the Print tools is always correct, even if more tools
were inserted and then the toolbar was recreated (in a different position).
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.
There were many problems if some options selecting the build of wxWidgets to
use were not specified at all, i.e. if the corresponding string was not used
in WX_STANDARD_OPTIONS() argument or if WX_STANDARD_OPTIONS() was not used at
all (which is perfectly possible and allowed).
In this case, the output of WX_STANDARD_OPTIONS_SUMMARY_MSG() was corrupted
(e.g. it could output "WX_DEBUG is" without any value and "PORT:" value was
empty) and, worse, as that macro is only cosmetic, WX_LIKE_LIBNAME() didn't
work correctly neither, making it difficult to check for the libraries using
it to construct their name (as many libraries from wxCode do).
Get rid of all these problems by simply treating empty/undefined variables as
meaning "auto detect" instead of having to set them to the special "auto"
value first. This makes sense as now we have just 3 states: 0, 1 or null,
instead of previous 4 (+ "auto") and is much more robust.
The code set WX_PORT to $TOOLKIT only if the latter was empty which made no
sense and also set WX_PORT to the never used nor documented anywhere else
$PORT if $TOOLKIT was not empty which made even less of it.
Just assign $TOOLKIT to WX_PORT if the former has a valid value.
Remove the never used 4th and 5th arguments of _WX_SELECTEDCONFIG_CHECKFOR
macro.
Also update the comment to better explain what does the macro actually do: it
doesn't "output the message" but rather sets a variable, with the message
being an optional side effect.
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.
When specific colours are turned on then custom colours are assigned to both category properties and their sub-properties. But when specific colours are turned off then only category properties are reverted to default colours what is misleading.
Now, all properties are reverted to default colours.
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.
Test executed from 'Category Specific Colours' menu is designed to work only for specific category properties which are present only on 'Standard Items' page.
Display a message if current page is not this one and therefore test cannot be executed properly. Also make menu item non-checkable if it is accessed from improper page.
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.
