Kevin Ollivier [Wed, 30 Dec 2009 17:41:29 +0000 (17:41 +0000)]
To support playing async sounds on the stack on Mac, do not delete the wxSoundData when its wxSound object is destroyed if it's in the queue of sounds to be played. Instead, mark it to be deleted and delete it after it has played.
Vadim Zeitlin [Wed, 30 Dec 2009 13:46:27 +0000 (13:46 +0000)]
Don't create an invalid iterator in wxDateTime::ParseTime().
Creating an iterator pointing beyond the string end resulted in an assert from
MSVC 9 CRT. Fix this by using wxString ctor taking length (which may be
greater than the length of the string) instead of the one taking two iterators
(which must both be valid).
Jaakko Salli [Tue, 29 Dec 2009 16:04:40 +0000 (16:04 +0000)]
Changed wxPropertyCategory to use same cell rendering code as regular properties. This allows labels for category columns other than the first. Rendering code was heavily modified to allow 'merging' of cells when needed.
Vadim Zeitlin [Mon, 28 Dec 2009 16:18:37 +0000 (16:18 +0000)]
Ensure that frame is re-laid out when its toolbar is deleted.
The code in wxFrameBase::SetToolBar() didn't work correctly when toolbar was
unset using SetToolBar(NULL) because the frame toolbar pointer was reset
before layout was done resulting in the frame not recognizing its (still
existing) toolbar child as one of its bars and so nothing was done at all when
the frame had a single child, as in the toolbar sample.
Correct this by carefully ensuring that the toolbar pointer is still set at
the moment of the layout but hide the toolbar to ensure that no place is
allocated for it.
Also mention that it is not necessary to call SetToolBar(NULL) at all if the
toolbar is being deleted anyhow in the sample as toolbar does this itself in
its destructor.
Vadim Zeitlin [Sun, 27 Dec 2009 19:40:28 +0000 (19:40 +0000)]
Don't call SetMinSize() when creating the window if no initial size was given.
Calling SetMinSize() is unnecessary in this case. It also results in GTK+
errors when creating wxFileDialog as it is not created yet when this is called
(but it does take care to pass wxDefaultSize to this function as its size
can't be set yet).
Vadim Zeitlin [Sun, 27 Dec 2009 19:40:15 +0000 (19:40 +0000)]
Correct wxUSE_MACOSX_VERSION_MIN setting when running under OS X 10.4.
sw_vers outputs e.g. 10.4.11 under 10.4 so comparing its result with just 10.4
is wrong, match it against "10.4*" using case instead to ensure that 10.4.11
is indeed recognized as 10.4.
Vadim Zeitlin [Sun, 27 Dec 2009 19:39:55 +0000 (19:39 +0000)]
Override some methods in wxF(F)ileStream to resolve ambiguities.
Override virtual methods IsSeekable(), GetLength() and OnSysSeek/Tell() to
forward to wxF(F)InputStream base class as otherwise it's impossible to use
them at all because of ambiguity between the versions inherited from this
class and wxF(F)OutputStream (even though the two versions should do the same
thing as they operate on the same file descriptor/handle).
Also improve documentation of these classes: provide a brief description,
correct the base classes.
Vadim Zeitlin [Sat, 26 Dec 2009 16:36:39 +0000 (16:36 +0000)]
Take into account the initial buttons state when creating wxGTK toolbar.
With wxMSW it is possible to call e.g. wxToolBarTool::Enable(false) on a tool
before calling wxToolBar::Realize() to create the tool in an initially
disabled state but this wasn't done in wxGTK version.
Override Realize() now under wxGTK to bring the native toolbar buttons state
in sync with the internal state of the corresponding wxToolBarTools.
Jaakko Salli [Sat, 26 Dec 2009 10:45:04 +0000 (10:45 +0000)]
Replaced 'InlineHelp' property attribute with 'Hint'; Use SetHint() wxTextCtrl and wxComboCtrl member function to set it; Added a small section about help string and hint text in propgrid overview
Kevin Ollivier [Fri, 25 Dec 2009 20:43:43 +0000 (20:43 +0000)]
Remove the native toolbar from the frame in Destroy() rather than the destructor, as removing it in the destructor causes resize / repaint events to fire on the native control, which then goes to wx controls being deleted.
Vadim Zeitlin [Fri, 25 Dec 2009 11:36:54 +0000 (11:36 +0000)]
Always show hint in text entries, even when they have focus.
It was impossible to show the hint for the initially focused child of a dialog
before, as the hint was hidden from the very beginning. By showing it always
we avoid this problem.
We may want to add an option/flag for SetHint() to make this configurable
later if somebody really needs to show hints only for as long as the control
doesn't have focus.
Vadim Zeitlin [Wed, 23 Dec 2009 21:42:06 +0000 (21:42 +0000)]
Erase toolbar background even if it doesn't contain any controls/spaces.
Minor correction to changes in r62971: we still need to hook WM_ERASEBKGND in
toolbar parent when painting the toolbar itself even when there are no dummy
separators in it (and so we don't need to paint them over). Without this, the
background of simple toolbars without controls was not erased correctly.
Vadim Zeitlin [Wed, 23 Dec 2009 13:56:55 +0000 (13:56 +0000)]
Don't pass 0 timer ids to ::SetTimer().
Creating timers with 0 id failed because Windows SetTimer() function requires
a non-zero id. Fix this by using a (impossible at wx API level) -1 id value in
this case instead.
Vadim Zeitlin [Tue, 22 Dec 2009 15:37:49 +0000 (15:37 +0000)]
Remove the test of erase background events from the toolbar sample.
Handling erase background events for toolbars never worked for the ports other
than wxMSW and now it doesn't work for MSW neither as we need to skip erasing
the background in WM_ERASEBKGND handler to avoid flicker which would result
from erasing the background twice, from there and from WM_PAINT handler which
must do it. So don't even try to test if it works, it's unlikely to be very
useful anyhow.
Vadim Zeitlin [Tue, 22 Dec 2009 15:37:43 +0000 (15:37 +0000)]
Finally really correct background erasing for wxMSW wxToolBar.
Do use TBSTYLE_FLAT and TBSTYLE_TRANSPARENT (the former actually implies the
latter) for MSW toolbar as it is the only way to avoid the flicker of toolbar
buttons. These styles were disabled before because of lack of understanding
about how they worked: with them, the toolbar supposes that its parent takes
care of erasing its background but wx didn't do this (in fact wxFrame did
accidentally erase toolbar background because of the use of Win32 client
rectangle, including tool/status bars, instead of wx client rectangle,
excluding them, in wxWindowMSW::DoEraseBackground(), but it didn't do it
correctly).
Now we allow hooking WM_ERASEBKGND events processing in a parent window by a
child one and use this to handle toolbar background erasing in toolbar itself.
We still prevent the native toolbar from drawing dummy separators and always
erase the area occupied by them ourselves and thus avoid the flicker entirely.
The only remaining flicker in the toolbar sample is that of embedded
wxStaticText control. It does appear with correctly transparent background and
bitmaps with alpha channel also (still) are drawn correctly in wxStaticBitmaps
embedded in the toolbar.
Finally, we still use solid background brush for toolbar but we can easily use
a themed background if really desired, there is just a single function to
change to do it (MSWGetToolbarBgBrush()).
Vadim Zeitlin [Tue, 22 Dec 2009 15:37:37 +0000 (15:37 +0000)]
Fix best size computation for buttons without image and with empty label.
If a button was initially created with an empty label (but without image
neither), its best size was computed and cached as being null. Correct this by
giving the button the default size instead, as expected.
add a detailed description to wxMenuItem::SetItemLabel() partially moving docs from wxMenu::Append; add usage examples; organize wxMenuItem functions in 3 sections (getters, setters, checkers) to make it easier to browse the docs; use @onlyfor tag where necessary instead of the (Windows only) text
Vadim Zeitlin [Sat, 19 Dec 2009 12:00:16 +0000 (12:00 +0000)]
Document wxSpinCtrlDouble in correct header file.
The public header for this class is wx/spinctrl.h, but it was documented in
wx/generic/spinctrg.h which didn't even correspond to an existing real header
file (which is called spinctlg.h). Move the documentation to wx/spinctrl.h and
remove the old file.
Vadim Zeitlin [Sat, 19 Dec 2009 11:17:32 +0000 (11:17 +0000)]
Always draw standard-sized checkboxes in generic wxDataViewToggleRenderer.
The checkbox should be always shown in its normal size, otherwise it looks
strange. And this also fixes the overflow of the checkbox in the next column
which happened if the size passed to Render() had negative width before.
Jaakko Salli [Sat, 19 Dec 2009 11:13:03 +0000 (11:13 +0000)]
In wxPropertyGrid::HandleCustomEditorEvent(), also filter out excess wxEVT_COMMAND_TEXT_UPDATED events that originated from wxComboCtrl-derived editors.
Vadim Zeitlin [Fri, 18 Dec 2009 22:31:54 +0000 (22:31 +0000)]
Don't create labels with wxST_NO_AUTORESIZE flag with empty size by default.
Since r57627 wxStaticText objects with wxST_NO_AUTORESIZE flag created with
wxDefaultSize were created with zero width. This accounted for the
disappearance of the labels for the toolbar controls (as could be seen in the
toolbar sample where the combobox label was not shown any more).
Fix this by explicitly setting the correct initial size after the correct
label is set.
Vadim Zeitlin [Fri, 18 Dec 2009 22:31:48 +0000 (22:31 +0000)]
Don't draw over dummy separators in MSW toolbar, just don't draw them at all.
Prevent the native toolbar from drawing the separators which we use simply as
placeholders by excluding them from the update region when handling WM_PAINT.
This reduces flicker by not redrawing the areas occupied by these separators
twice and also prevents them from ever being shown (you could see them briefly
appear before being erased before).
The other toolbar tools still flicker though, there doesn't seem to be any
simple way to prevent the control from entirely invalidating itself whenever
it is resized.
Vadim Zeitlin [Fri, 18 Dec 2009 20:49:29 +0000 (20:49 +0000)]
Don't explicitly set the background colour for wxChoice.
This is unnecessary and results in flicker when the control is resized because
we explicitly erase its background ourselves and then it does it itself.
Vadim Zeitlin [Fri, 18 Dec 2009 20:49:23 +0000 (20:49 +0000)]
No real changes, just change type of MSWGetBgBrush() argument.
Pass wxWindow instead of HWND to it as in most cases we already have wxWindow
for the HWND we have and calling wxFindWinFromHandle() once more is
unnecessary.
This also makes the code of MSWGetBgBrushForChild() slightly simpler.
Vadim Zeitlin [Fri, 18 Dec 2009 20:49:15 +0000 (20:49 +0000)]
Don't force themed background for wxToolBar under MSW, just use the default.
Native toolbars don't have themed background under Vista/7 and don't look good
with rebar background (which is the same one as used for the menus) as
toolbars don't appear on the top of the window.
Erasing background ourselves also results in flicker and display problems and
makes the code much more complicated. Simply don't do this to avoid all the
problems.
Vadim Zeitlin [Fri, 18 Dec 2009 14:47:18 +0000 (14:47 +0000)]
Only call GetTextMetrics() in wxDC::GetTextExtent() if necessary.
A micro-optimization: avoid ::GetTextMetrics() call if we don't use its
results (as is the case if neither descent nor external leading were
requested).
Vadim Zeitlin [Fri, 18 Dec 2009 14:47:08 +0000 (14:47 +0000)]
Call SymCleanup() in wxStackWalker to fix problem with next call to it.
Calling SymInitialize() second and subsequent times failed (and hence so did
wxStackWalker::WalkFrom() and other methods) as we didn't call SymCleanup()
because of some problems with old versions of debughlp.dll. These problems
don't seem to exist any more so do call SymCleanup() so that we can walk the
stack more than once.
Vadim Zeitlin [Fri, 18 Dec 2009 14:46:38 +0000 (14:46 +0000)]
Restore the use of the correct brush for toolbar background erasing.
The call to SetBrush() was mistakenly removed in r62850 but it is needed
because wxClientDC only inherits background colour but not the brush used by
DrawRectangle() call in wxToolBar::MSWEraseRect(), so the wrong colour was
used under systems < Vista.
Vadim Zeitlin [Thu, 17 Dec 2009 17:51:12 +0000 (17:51 +0000)]
Correct wxDateTime::GetWeekOfMonth() for days in the beginning of January.
This function was implemented in terms of GetWeekOfYear() which made it tricky
to get it right as GetWeekOfYear() can, correctly, return week number for the
previous year for the first days of January (and also from the next one for
the last days of December).
Replace this implementation with a simple one directly counting the number of
weeks since the first of the month, this seems to be much simpler and does
pass the new unit test case which the old version failed.
Also make the unit test failures more informative by using
WX_ASSERT_EQUAL_MESSAGE() instead of CPPUNIT_ASSERT_EQUAL().
Vadim Zeitlin [Thu, 17 Dec 2009 16:44:09 +0000 (16:44 +0000)]
Always use FVIRTKEY for the accelerators under MSW.
Not using FVIRTKEY results in problems in non-US keyboard layouts and, in
fact, we were already always using it because wxCharCodeWXToMSW() returned
true in its output IsVirtual argument most of the time.
Just do it always now and also remove IsVirtual parameter with badly (if at
all...) defined meaning from wxCharCodeWXToMSW() as it's not used anywhere any
longer.
Vadim Zeitlin [Tue, 15 Dec 2009 22:44:54 +0000 (22:44 +0000)]
Avoid GTK+ errors when using AUI wxPseudoTransparentFrame hack.
wxPseudoTransparentFrame is not a top level window at all and the code in
wxGTK wxTopLevelWindow::DoSetSizeHints() fails for it when it is called from
wxWindowBase::CreateBase() because of it and spits GTK+ errors as it calls
gtk_window_set_geometry_hints() with NULL widget.
Fix this by simply skipping wxTopLevelWindow implementation of this method in
wxPseudoTransparentFrame. A better fix would be to get rid of this hack
completely, of course.
Vadim Zeitlin [Tue, 15 Dec 2009 21:12:06 +0000 (21:12 +0000)]
Remove asserts in wxChoicebook::Get/SetPageImage().
It's better to silently return an error code than assert when these methods
are called as their failure is relatively harmless and the user code may call
them via base class pointer without caring if it works with a control which
supports images or not.
Vadim Zeitlin [Mon, 14 Dec 2009 19:17:12 +0000 (19:17 +0000)]
Avoid painting generic wxDataViewCtrl if it has no columns.
The code in wxDataViewMainWindow::OnPaint() relied on having at least the
first column and didn't work for a completely empty control. Just don't paint
it at all in this case as it's unnecessary anyhow.
projects / wxWidgets.git / log
