Setting the background colour for the status bar explicitly is unnecessary and
probably prevents it from rendering correctly with some themes. Simply remove
the call to SetBackgroundColour() from wxStatusBar::Create().
We should also define Get[Class]DefaultAttributes() in wxStatusBar in the
future.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66231 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Any border specified for wxSplitterWindow was explicitly discarded when
creating it but there doesn't seem to be any reason to forbid it, the original
code probably predated the addition of wxWindow::GetDefaultBorder() which
allowed to have different borders by default for different classes.
In any case, simply remove this code now to allow creating splitters with
borders if so desired.
Closes#12413.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66230 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Move DeletePendingObjects() call from ProcessPendingEvents() to ProcessIdle()
to ensure that we delete the objects marked for destruction even if the
application is sitting in a tight OnIdle() loop, i.e. if the idle event
handler keeps requesting more events.
Also make sure that the event loop terminates if its OnExit() was called even
if the idle event handler continues to request more events.
Closes#12424.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66229 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
An assert in wxTimerWndProc() could be provoked by valid user code which
simply started and stopped the timers quickly enough because a WM_TIMER could
have been already generated just before we stopped the timer.
Simply ignore events from unknown timer under assumption that they must come
from the recently stopped ones instead of asserting.
Ideally we'd somehow distinguish between the situation described above and the
really bogus events which could indicate bugs in wx code or a change in
behaviour in a future version of Windows but there is no easy way to do it so
for now just settle for not asserting in normal case.
Closes#10052.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66228 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use wxControl-provided CreateControl() and MSWCreateControl() methods to
create the status bar instead of duplicating their code in its Create().
Also translate wx styles to MSW ones in overridden MSWGetStyle() now.
In addition to making the code smaller and more clear, this fixes the
non-respect of the styles specified at status bar creation (e.g. border),
see #12655.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66227 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxStatusBar is no less a control than wxToolBar and deriving it from wxControl
gives access to convenient native control creation functions under MSW (which
will be used by the next commit).
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66226 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
We need to account for the full size of status bar, including potential
borders, when calculating the client size of the frame containing it.
Closes#12697.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66225 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Update the currently selected page before generating
wxEVT_COMMAND_NOTEBOOK_PAGE_CHANGED event in wxMSW wxNotebook. This is more
consistent with other ports and more logical as "-ED" events are supposed to
be sent after the action they notify about is completed. And it also allows to
set the focus in this event handler whereas any attempts to do it would have
been disregarded before as changing the active page resets focus.
Notice that this does introduce an incompatibility: calling
wxNotebook::GetSelection() from PAGE_CHANGED event handler now returns the new
page and not the old one as before. Again, this is more logical and more
consistent.
Closes#12688.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66224 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxScintilla code uses wxVector<> which brings in wxDEBUG_LEVEL-dependent code
so we must use the wxDEBUG_LEVEL value consistent with the rest of the library
when building it.
Simply pass wxDEBUG_LEVEL definition on the compiler command line if it's
different from the default.
Closes#12626.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66223 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
We need WXUSINGDLL even in monolithic build because Scintilla references wx
debugging functions (wxOnAssert(), wxTheAssertHandler &c) which still must be
seen as being exported from the (monolithic) DLL in this case.
See #12626.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66222 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
GetFamily() returns wxFONTFAMILY_DEFAULT and not wxFONTFAMILY_UNKNOWN since
r65670.
Correct the test to handle wxFONTFAMILY_DEFAULT as allowed value.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66221 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This change is not needed any longer after r66219 which fixed the real
underlying problem, i.e. that attempting to load an invalid XRC file resulted
in failures when loading all subsequent XRC files.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66220 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Attempting to load a resource that couldn't be loaded resulted in
wxXmlResource::Load() returning false for this and _all_the_subsequent_ calls
to it because each call to Load() reattempted to reload all resources,
including the one(s) that failed to load initially.
Instead, try to load just the resource(s) that we should load right now and
ignore all the other ones. Also, don't add entries for the one(s) that we fail
to load.
This fixes the unit test failures in the XRC test case which was affected by
the test checking that XRC couldn't be loaded from garbage that ran before it.
It also makes the code simpler by ensuring that wxXmlResourceDataRecords
elements always have a valid wxXmlDocument associated with them.
Also clean up the code: use wxScopedPtr instead of manually deleting pointers
and reorganize #if checks to be easier to follow.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66219 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The path being normalized could have come from user and there doesn't seem to
be any point in complaining about too many ".."s in it when we can handle them
correctly instead.
So simply ignore the extra ".."s for the absolute paths and keep them
unchanged for the relative ones instead of returning an error.
See #10960.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66218 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Try to explain the different exception handling strategies more clearly in the
overview and also update OnUnhandledException() documentation.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66205 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Check that the provided day is strictly positive and also that the month is in
valid range: while it should always be, considering that it's an enum element,
in practice people often cast ints to wxDateTime::Month with potentially fatal
results. Catch this with an assert in wxDateTime::Tm::IsValid().
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66203 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This header was only included implicitly via wx/msw/uxtheme.h and thus the
code failed to compile with wxUSE_UXTHEME==0 but wxUSE_DYNLIB_CLASS==1.
See #12664.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66202 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This method can be used for menu bar entries also since the previous commit.
Do mention that SetTitle() can't be used to change a menu bar menu title
however.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66179 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Store the titles of the menu bar menus in the menu objects themselves. This
makes wxMenu::GetTitle() return the expected result for them (which also fixes
the current unit test failures for wxMSW) and makes wxMenuBar code simpler.
This removes the wxMenuInfo class which existed for XTI purposes only but as
it was apparently unfinished and MSW-specific it shouldn't be a big loss.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66178 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Make more local variables const. Use consistent spacing. Don't use needless
comparison with NULL. Don't avoid not using double negation.
See #12682.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66177 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxMenu::GetTitle() returned a string in GTK+ format (i.e. using underscores
instead of ampersands) instead of the expected wx one.
This is, of course, the right thing to do and it also fixes
wxMenuBar::FindMenuItem() as a side effect.
Closes#12672.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66175 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Mention in the setup.h comment that wxDynamicLibrary is used in a lot of
places internally and disabling it can result in a loss of a lot of important
functionality.
See #12664.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66174 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
A virtual list control must override wxListCtrl::OnGetItemText() method and
wxMSW native implementation asserts if this is not the case (the generic one
should arguably do it as well).
Avoid the asserts by providing a dummy implementation of OnGetItemText() in
the unit test.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66171 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Fixing the implicit focus grabbing by wxTreeCtrl::SelectItem() in r65905 broke
its unit test case as the simulated key event was not delivered to wxTreeCtrl
itself any more.
Fix this by simply setting the focus to the tree explicitly before sending it
any key strokes.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66170 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The assert added in r66053 checking that we couldn't have tooltips for child
windows if we didn't have the tooltip for the main one turned out to be wrong,
at least in wxRadioBox case it's perfectly possible to have the tooltips for
the individual radio buttons without having one for the box itself.
Replace the assert with a simple if check.
This fixes a unit test failure in RadioBoxTestCase.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66169 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Extract code common to several wxImage methods creating new images based on an
existing one in a new MakeEmptyClone() method.
Closes#12682.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66167 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Parsing an incomplete date with nothing but whitespace and/or date delimiter
characters at the end crashed as we happily went beyond the end of string.
Fix this by not using a loop which didn't check for the iterator validity.
Closes#12685.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66166 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Deal with the lack of scope around variables declared inside the for loop in
this compiler, previously it gave "error C2360: initialization of 'x' is
skipped by 'case' label" message and also complained about redefinition of 'x'.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66157 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The code closing all file descriptors inherited from the parent in the child
process created by wxExecute() was removed in r57324 by mistake (probably
due the fact that its meaning was poorly explained) but we still do need to do
this, of course, to avoid descriptor "leaks" (e.g. the parent couldn't really
close any of them).
Restore the code for closing all unneeded file descriptors in the child in
slightly modified form and add a comment pointing to an URL explaining how to
do it better in the future.
Closes#12636.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66153 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Since the child pipe was made non-blocking in r65993, it became possible to
write to child process without deadlocking when the pipe became full. However
this still resulted in an error from wxFileOutputStream as it didn't handle
EAGAIN returned from write() any differently than any other error, even though
it is an expected situation in this particular case.
Change Unix wxExecute() to use wxPipeOutputStream which ignores EAGAIN unlike
wxFileOutputStream to fix this.
See #12636.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66152 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Renamed the symbol indicating whether pipe-based streams are available from
HAS_PIPE_INPUT_STREAM to HAS_PIPE_STREAMS as it's not really input-specific.
See #12636.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66151 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Set hot spot coordinates for the rotated image if the original one had them.
Also handle the case when the source image has both alpha and mask correctly.
Closes#3680.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66145 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxOSX rearranges the standard menu items such as wxID_EXIT and wxID_ABOUT and,
for the former, changes its text to "Quit", so don't use them in the menu unit
test which expects to find the items in the menus to which they were added and
exactly with the labels used when adding them.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66144 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Putting the cursor to the end of the control when the editing starts doesn't
make much sense as this should be the default behaviour anyhow and, worse,
this results in an assert under wxMSW where a read-only wxComboBox doesn't
have any cursor to move.
Closes#12446.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66143 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The scrollbar positions stored in wxWindow::m_scrollPos were not initially
correct in wxGTK because wxScrollHelper::SetScrollbars() didn't update them
and only set the values of the underlying GtkAdjustments themselves. This
resulted in filtering out of the first scroll event as the code (wrongly)
believed that the scrollbar position hadn't changed.
Fix this by setting m_scrollPos to the real scrollbar positions.
Closes#12468.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66142 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Asserts should be only triggered by programming errors, not by user actions,
and the assert checking that the value is either 0 or 1 in
wxConfigBase::DoReadBool() could happen if the user edited the file and put a
wrong value into it.
Replace the assert with a warning message.
See #11437.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66140 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
