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.
TOOLKIT is never set to "MAC" at all (it is one of OSX_{CARBON,COCOA,IPHONE})
so it is not necessary to test for it. And for the other cases the special
logic for OS X ports was the same as the general case so it seems to be
unnecessary as well.
Vadim Zeitlin [Sun, 13 Dec 2009 12:52:47 +0000 (12:52 +0000)]
Test for sw_vers availability before calling it in configure.
There is no sw_vers when cross-compiling, just assume 10.4 system in this
case and point the user to --with-macosx-version-min which can be used to
override this.
Vadim Zeitlin [Sun, 13 Dec 2009 12:52:42 +0000 (12:52 +0000)]
Rename --with-cocoa configure switch to --with-old_cocoa to avoid confusion.
Change --with-cocoa to be synonym for --with-osx_cocoa, add --with-carbon as a
synonym for --with-osx_carbon for consistency and --with-osx as a synonym for
--with-mac.
Vadim Zeitlin [Thu, 10 Dec 2009 03:04:19 +0000 (03:04 +0000)]
Add support for stretchable spaces to wxToolBar.
Stretchable spaces consume all extra toolbar space not allocated to the fixed
size items. They can in particular be used to right-align (some) toolbar tools.
Add and document the new API, change the sample to show it and implement it
for MSW, GTK and OS X/Cocoa.
Also refactor MSW background erasing/repainting code to avoid duplicated calls
to DrawThemeBackground(), call it from a new helper MSWEraseRect() function.
Note that we may want to add support for "invisible" separators, IOW
non-stretchable spaces. This could be easily done for MSW after the changes in
this commit and is supported natively by GTK+ and Cocoa so implementing this
would be trivial if there is any interest.
Vadim Zeitlin [Thu, 10 Dec 2009 03:04:07 +0000 (03:04 +0000)]
Rename gtk{,1}/tbargtk.{h,cpp} to toolbar.{h,cpp}.
We don't use crptknm$port.cpp naming convention even for MSW any more and
there is really no reason to continue to do it for just this one file in
wxGTK.
Vadim Zeitlin [Thu, 10 Dec 2009 02:59:16 +0000 (02:59 +0000)]
Set correct toolbar width in wxMSW wxFrame.
The hack introduced in r22410 artificially set wrong size for toolbar under
MSW. This completely breaks any calculations that can be done using it (e.g.
to find the space available for the stretchable part of the toolbar) and is
completely and utterly unexpected.
Revert it, toolbar flicker must be dealt in another way if it is still a
problem.
Vadim Zeitlin [Thu, 10 Dec 2009 02:59:02 +0000 (02:59 +0000)]
No changes, just slightly simplify the tool insertion code.
Added a helper DoInsertNewTool() function to avoid code duplication and ensure
that we never forget to delete a new tool if inserting it into the toolbar
failed.
Also explicitly document that the tool passed to the public InsertTool() is
not owned by the toolbar and so must be deleted by the caller if its insertion
failed.
Peter Cawley [Wed, 9 Dec 2009 18:48:41 +0000 (18:48 +0000)]
Rewrote wxRibbonPage realisation and layout code to avoid setting the position and size of panels multiple times.
Fixed memory leak in wxRibbonToolBar::Realize().
Vadim Zeitlin [Wed, 9 Dec 2009 14:59:26 +0000 (14:59 +0000)]
Avoid outputting the assert message twice in non-GUI code.
As we always log the assert message in ::ShowAssertDialog() itself there is no
need to log it again in wxAppTraitsBase::ShowAssertDialog().
Also show the "please wait while generating stack trace information" in
wxAppTraitsBase::GetAssertStackTrace() itself instead of doing it in both
places which call it.
Vadim Zeitlin [Wed, 9 Dec 2009 14:59:13 +0000 (14:59 +0000)]
Don't limit the number of stack frames in GTK assert dialog to 20.
This dialog uses a scrollbar to keep its vertical size reasonable in any case
so there is absolutely no danger of making it too tall even if we show more
frames in it.
Vadim Zeitlin [Wed, 9 Dec 2009 14:59:08 +0000 (14:59 +0000)]
Better handling for asserts in non-main threads.
Don't call wxTrap() when an assert in a non-main thread fails. As asserts are
now always enabled by default, this is not a good idea. Instead just show the
full details about the assert failure using wxMessageOutputDebug under the
platforms without MT-safe message box function (i.e. everything but MSW
currently).
Add a possibility to test an assert happening in non-main thread to the except
sample.
Vadim Zeitlin [Wed, 9 Dec 2009 14:59:01 +0000 (14:59 +0000)]
No real changes, just remove __WXDEBUG__ tests.
These tests are unnecessary now because asserts are almost always enabled. We
could test for wxDEBUG_LEVEL but the code still compiles even if it's defined
as 0 so there doesn't seem to be any need for it.
Vadim Zeitlin [Tue, 8 Dec 2009 15:56:14 +0000 (15:56 +0000)]
Implement wxWindow::DoGetBorderSize() in the trivial case of wxBORDER_NONE.
This fixes an assert in wxGenericStaticText which overrode
DoGetBestClientSize() but not DoGetBorderSize().
It would still be useful to implement DoGetBorderSize() in wxGTK (and other
ports) in general too as using wxGenericStaticText with non-default border
still doesn't work.
Vadim Zeitlin [Tue, 8 Dec 2009 15:36:51 +0000 (15:36 +0000)]
Fix event object in wxSysColourChangedEvent.
The handler for this event in the base class incorrectly changed the event
object of the original event instead of setting it for the event being sent to
the window children as it was supposed to.
Vadim Zeitlin [Tue, 8 Dec 2009 15:24:59 +0000 (15:24 +0000)]
Don't set the initial size as minimal size for top level windows.
Correct the change of r62814: only call SetMinSize() for non-top-level windows
as the user should be able to resize the top-level ones to be smaller than
their initial size.
This also fixes the GTK+ warning resulting from calling wxTLW::SetMinSize()
from the ctor, before the window is realized.
Vadim Zeitlin [Mon, 7 Dec 2009 23:37:36 +0000 (23:37 +0000)]
Set initial window size as its minimal size.
The change of r62306 broke the code which relied on the window created with a
given initial size to never become smaller than this size. This was to be
expected because the best size of such window is now (1, 1) and not its
initial size but we still need to preserve the old behaviour for compatibility
and also because it usually does make sense to avoid shrinking the window with
an explicitly specified initial size beneath this value.
So call SetMinSize() with the initial size explicitly now in wxWindowBase
ctor.
Vadim Zeitlin [Mon, 7 Dec 2009 13:37:01 +0000 (13:37 +0000)]
Generate erase background events for native controls too under MSW.
Remove the test which prevented the generation of erase background events from
wxMSW::wxWindow::HandleEraseBkgnd(). Although it is true that native controls
mostly erase background on their own, there are exceptions: we must erase the
background of wxToolBar ourselves, for example. More importantly, there is no
reason to prevent the user code from defining wxEVT_ERASE_BACKGROUND handlers
for the native controls as this works just fine under MSW (although it doesn't
under GTK nor probably other ports...). So also add a test erase background
handler to the toolbar sample to verify that this does work.
Vadim Zeitlin [Mon, 7 Dec 2009 05:01:14 +0000 (05:01 +0000)]
Move wxMSW wxTextCtrl::GetDefaultAttributes() to wxTextCtrlBase.
This commit doesn't introduce any changes in the control behaviour, it simply
moves the existing method to the base class because it is not MSW-specific.
Also implement wxTextCtrlBase::GetClassDefaultAttributes() because if a class
implements GetDefaultAttributes() it should implement it as well.
Vadim Zeitlin [Mon, 7 Dec 2009 03:04:39 +0000 (03:04 +0000)]
Define MY_DLL_BUILDING symbol for dll sample DLL build.
This is necessary to properly define MY_DLL_DECL as either WXIMPORT or
WXEXPORT depending on whether my_dll.h is included from DLL itself or from
outside it. Without this, MSVC generated warnings about inconsistent dll
linkage.
Vadim Zeitlin [Sun, 6 Dec 2009 02:29:56 +0000 (02:29 +0000)]
Minor corrections to ToWChar() comment.
Don't refer to the non-existent outputBuf parameter and don't imply that the
value of dstLen matters to decide whether we really convert or not -- only
whether dst pointer itself is NULL or not does.
Václav Slavík [Sat, 5 Dec 2009 18:54:40 +0000 (18:54 +0000)]
Added samples/dll for showing how to use wxWidgets to implement
a DLL that is used from another application written with a different
toolkit (or different wx version).
Vadim Zeitlin [Sat, 5 Dec 2009 17:30:53 +0000 (17:30 +0000)]
Don't lock global mutex when deleting wxThread to avoid deadlocks.
Calling out the user-defined wxThread dtor while holding gs_mutexDeleteThread
lock is a bad idea as it may result in deadlocks if the dtor deletes another
thread. Only lock the mutex directly before manipulating the data it protects.
projects / wxWidgets.git / log
