Don't include <initguid.h> too soon, as this affects the headers included
after it instead of just our own uses of DEFINE_GUID() as intended.
This resulted in link errors because of duplicate definitions of the many
standard GUIDs when using MinGW for which we include, for whatever reason,
shlguid.h.
This fixes the change of r67573.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74600 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Add wxHTTP::SetMethod().
Also simplify the code by determining the method to use in Connect() instead
of doing it in BuildRequest() itself.
Get rid of the now unused wxHTTP_Req enum.
Closes#15354.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74597 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Since r74585, wxWindow::SetCanFocus() is called from wxStaticBoxBase ctor,
i.e. before the real window is created, and this results in a crash in wxGTK
where SetCanFocus() needs a valid widget.
Fix this simply by doing nothing in SetCanFocus() if the widget is not created
yet as this should result in the same behaviour as before r74585. This doesn't
seem like the right thing to do, however, and we should probably remove this
call from wxStaticBoxBase ctor and do it in wxStaticBox implementation itself
instead.
Closes#15358.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74594 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
There was a bug similar to the one in the preceding commit with radio boxes
under wxMSW too: if all radio box buttons were disabled (or hidden, although
this should be much more rare in practice, unlike the disabled case which was
deemed to be rare in r74583 commit message but turned out to actually happen),
the radio box still pretended to accept focus but didn't really do it.
Fix this by allowing to override wxWindow::CanBeFocused() and do it in
wxRadioBox to check whether we have any enabled visible items.
Also add a check for CanBeFocused() to wxControlContainer code.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74586 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxControlContainer::AcceptsFocusFromKeyboard() returned true even if the
control didn't have any currently enabled -- and hence accepting focus --
children. This resulted in strange wxEVT_NAVIGATION_KEY propagation as it
unexpectedly wasn't handled in the control which pretended to accept focus and
instead bubbled up back into the parent, resulting in the focus returning to
the first child of the parent instead of skipping the static box with disabled
children and going to the next enabled child.
Fix this by checking that we have children that can be focused right now and
not only children that are focusable. Notice that this doesn't take care of
calling wxWindow::SetCanFocus() correctly when the children enabled/disabled
state changes so there might still be other problems, notably under wxGTK
where SetCanFocus() does something non-trivial, but it at least improves
things under wxMSW.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74585 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Radio boxes refused to take focus from keyboard as their
wxControlContainer::AcceptsFocusFromKeyboard() always returned false because
the base wxStaticBox class disabled setting the focus to the control itself
and wxRadioBox doesn't have any children at wx level in wxMSW.
Fix this by reenabling "self focus" in wxRadioBox to make it possible to
accept focus from keyboard. This is not ideal as it doesn't take into account
e.g. radio boxes without any items or with all items disabled or hidden, but
this should be rare and would require virtualizing all children access at
wxControlContainer level, i.e. would be quite non-trivial so don't do this for
now as this, at least, fixes the navigation in common/normal case.
Also remove the unnecessary AcceptsFocus() override from wxRadioBox as this is
now done at wxControlContainer level.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74583 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Extract the call to wxWindow::SetCanFocus() into a separate
UpdateParentCanFocus() function as it can be necessary to do it from places
other than UpdateCanFocusChildren() too.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74582 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The cursor didn't change to a link one when the mouse was over link areas in
an image map.
Fix this by generalizing wxHtmlCell::GetMouseCursor() into GetMouseCursorAt().
Closes#15350.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74570 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Deal correctly with updating the indices when a radio item is inserted into an
existing radio group (which wasn't done previously and resulted in a unit test
failure in MenuTestCase::RadioItems()) and also with inserting the normal
items before an existing radio group as the stored indices were not updated
correctly.
The code is still ugly and it probably wouldn't be a bad idea to reuse
wxMenuRadioItemsData used in wxMSW for similar purposes, but at least the unit
tests pass now.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74548 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Get rid of this pseudo-Hungarian notation and make the naming of the variables
consistent across the whole file.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74545 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This code was probably copied from wxUniv but was wrong as we can't rely on
the items being always inserted in order. This commit on its own fixes
removing the first radio group menu item but it also makes possible to
properly implement the insertion of new items in the middle of an existing
radio group which couldn't be done with m_startRadioGroup approach at all.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74544 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This DOMRange method, previously used in GetSelectedText(), seems to provide
exactly what we need so there doesn't seem to be any reason to use JS to get
the selection text, especially as it didn't even work under OS X 10.8 and
returned an empty string in the unit test.
The unit test still needs adjustment to pass because we don't get back exactly
the same HTML as we used originally, but with more relaxed matching it does
pass now.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74541 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Under OS X the markup string was returned, unlike in all the other ports,
resulting in a unit test failure, fix this.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74540 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Nothing is going to work without the console apps/base traits support for the
event loop but at least make it compile.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74531 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Allow measuring the descent and external leading of an empty string by
measuring just a space instead in wxOSX. This makes the behaviour more
consistent with wxMSW and makes the unit test added in r74464 pass under OS X
too.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74524 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Clang detects that a class member is unused (under non-Windows systems) which
is quite impressive but not really useful in this particular case, so suppress
this warning by "using" it.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74519 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
And also less annoying: remove the messages from DoMoveWindow() which could be
given during resizing but not necessarily corresponded to the final control
size.
And give more details about which control is not being given enough space when
a too small size is given in the ctor.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74516 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The change of r71371 resulted in using the already destroyed (implicitly, done
as part of destroying the wxView that failed to initialize) wxDocument in
wxScopeGuard destructor.
Avoid this and make the old (i.e. pre-r71371) code exception safe while
keeping its semantics exactly, i.e. only delete all views if the document
still exists.
Also add a comment explaining what's going on here because the ownership rules
in docview code are frankly crazy.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74515 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The free space near the tabs was always filled with the default light grey
colour, use wxNotebook background colour itself to fill it now.
Do it by changing the code in wxNotebook::OnPaint() to use the background
colour brush and ExtFloodFill() to paint over the default grey, instead of the
patterned background brush which is supposed to be used for the pages area
only and not for the tabs and which was not even taken into account anyhow as
the default window proc erases the entire contents of the DC we pass to it
anyhow (at least in the default top-aligned tabs case).
Also inherit the background colour from parent by default now, this ensures
that wxNotebook blends with its parent when its background colour has been
explicitly set by default, without the need to call its SetBackgroundColour()
explicitly.
See #13745.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74505 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Using wxNOT_FOUND and an unsigned size() return value in the same operator ?:
resulted in wxNOT_FOUND being converted to an unsigned size_t type and while
converting it back to (signed) long worked in 32 bit builds where long and
size_t have the same size, it was broken in 64 bit builds where their sizes
are different.
Thanks g++ for catching this one.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74493 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
