Vadim Zeitlin [Wed, 7 Aug 2013 11:08:38 +0000 (11:08 +0000)]
Document light grey colour handling in wxMSW wxBitmap::LoadFile().
For historical/compatibility reasons we handle this colour as transparent in
wxMSW when loading the bitmaps from resources, but this is rather not obvious
for the new users, so document it and provide a way of compensating for this
in the documentation as well.
Vadim Zeitlin [Wed, 7 Aug 2013 11:08:33 +0000 (11:08 +0000)]
Define __VISUALC__ for ICC under Windows again.
During the refactoring of r74496, the logic of the check for Intel compiler
was slightly altered resulting in not defining __VISUALC__ for it any longer
which broke compilation with it.
Restore this definition now to fix it, even though it could admittedly be
better to explicitly check for __INTELC__ in the places where we currently
only check for __VISUALC__ and reserve the latter only for the case when we
are really using MSVC.
Vadim Zeitlin [Wed, 7 Aug 2013 11:08:21 +0000 (11:08 +0000)]
Update Travis configuration to run tests and build more configurations.
Install libcppunit-dev in order to be able to run the unit tests (at least the
non-GUI ones for now).
Also build in several configurations: shared/static, multilib/monolithic and
also STL. This should help to find problems appearing only in some specific
build variants.
Vadim Zeitlin [Wed, 7 Aug 2013 11:08:12 +0000 (11:08 +0000)]
Don't use DDEExec registry key in wxMSW wxExecute() if it's empty.
Some file types have DDEExec subkey in the registry but no value for it, don't
use DDE for launching the files of these types in this case as this only
results in errors.
Vadim Zeitlin [Tue, 6 Aug 2013 17:00:00 +0000 (17:00 +0000)]
Don't generate any events from wxSpinCtrl and wxSpinCtrlDouble methods.
After the changes of r53758 wxMSW didn't generate any wxEVT_TEXT events but
this was still the case for the generic version (and hence for
wxSpinCtrlDouble under MSW too) and wasn't documented.
Fix all versions to avoid sending events for programmatic actions, add unit
tests checking this behaviour and document it.
Vadim Zeitlin [Tue, 6 Aug 2013 16:59:54 +0000 (16:59 +0000)]
Add test for absence of events from wxSpinCtrlDouble ctor.
Run the same NoEventsInCtor() test as we already had for wxSpinCtrl for
wxSpinCtrlDouble as well.
Unfortunately currently there is no way to reuse the tests between these two
classes, we should refactor these test cases to use a common
SpinCtrlTestCaseBase<T> base class.
This method allows to get the full width needed by wxPropertyGrid and is
useful for determining the space to allocate for it, e.g. when creating a
popup showing the property grid, as shown by the changes to the sample.
Paul Cornett [Tue, 6 Aug 2013 06:05:38 +0000 (06:05 +0000)]
Rewrite ConvertToGreyscale() and ConvertToDisabled()
They do almost the same thing, so use almost the same code.
Fixes ConvertToDisabled() modifying its own data.
Closes #15389
Václav Slavík [Sat, 27 Jul 2013 19:39:37 +0000 (19:39 +0000)]
Make wxComboCtrlBase::Set*groundColour() methods public.
SetForegroundColour() and SetBackgroundColour() were -- presumably
accidentally -- protected in wxComboCtrlBase, even though they are
documented public virtual methods of wxWindow. This prevented their
use from user code.
Remove all lines containing cvs/svn "$Id$" keyword.
This keyword is not expanded by Git which means it's not replaced with the
correct revision value in the releases made using git-based scripts and it's
confusing to have lines with unexpanded "$Id$" in the released files. As
expanding them with Git is not that simple (it could be done with git archive
and export-subst attribute) and there are not many benefits in having them in
the first place, just remove all these lines.
If nothing else, this will make an eventual transition to Git simpler.
Fix duplicate symbol link errors in wxMSW wxTextEntry code.
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.
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.
Fix tab navigation bug with radio boxes without enabled items.
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.
Fix tab navigation bug with static boxes without enabled children.
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.
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.
No real changes, just refactor wxControlContainer code a little.
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.
Rearrange Windows checks in wx/platform.h to be more logical.
Use __WINDOWS__ symbol as the primary symbol indicating Windows instead of
using all of _WIN32, __WIN32__ and __WINDOWS__.
Also automatically define __WINDOWS__ if __WXMSW__ is defined as this port
only can be used under Windows and doing it like this fixes compilation in the
case when the platform ends up being not defined at all, closes #15342.
Finally, don't assume Windows by default but give an error if we can't detect
the platform. This shouldn't happen in practice but seems a safer thing to do
if it ever does happen.
Just forward Stricmp() in wx/string.h to wxCRT_StricmpA().
Don't redo the tests already done in wx/wxcrtbase.h in wx/string.h too,
especially as they were not done correctly there (they didn't take into
account the case of MinGW in strict ANSI mode). Just call wxCRT_StricmpA().
This also allows us to get rid of HAVE_STRCASECMP_IN_STRING[S]_H tests in
configure.
Document the release scripts really used for making releases.
End the polite fiction that build/tools/create-archive.py is used to build the
release because it isn't and all the last releases were built using different
scripts. Document their use in more details.
Use "INNO" env var in Inno Setup script only if it's defined.
Just use the sources directory itself if %INNO% is not defined. In fact, I
think we could always use the source directory, actually, but just in case
there was some reason to do it like this, keep using %INNO% if it is defined.
Also check that WXW_VER environment variable that we use is, in fact, defined.
FIX: Use relative path, not %WXWIN% in ISS script.
Add manually created VC10 project and solution files for the library.
These files were obtained by importing the VC9 files and then setting up the
dependencies correctly in the solution. This is just a temporary solution and
we'll hopefully generate them with bakefile-1 for the 3.0 release but for now
this is better than nothing.
Fix insertion of radio menu items in wxOSX wxMenu.
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.
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.
Use [DOMRange markupString] to get selection source.
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.