We don't need to handle the documentation files separately when they are
already taken care of together with everything else anyhow.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74562 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
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.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74561 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Generate the output file in the parent of the sources directory and take care
of copying it to c:\daily in bld_chm_exe.bat itself.
This allows to use wxwidgets.iss without that batch file and also on systems
without c:\ drive at all.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74560 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
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.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74559 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
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.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74549 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
The latter will be convenient to use in the upcoming changes to wxOSX radio
items management code and add the former for the symmetry.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74542 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
The changes of r74532 were incomplete/wrong and the fix of r74536 didn't
entirely fix the logic here, so try to do it again, hopefully correctly this
time.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74537 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The latter file is also used when building from the command line while the
former is only used in Xcode build, as its name indicates (which didn't help
me to notice it, however).
Also restore the test for wcsftime() in configure as it is available even on
older systems but do not test for strnlen() -- as it is not.
These changes amend those of r74523.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74534 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
The tests for these functions may succeed on the system we're running under
but the functions may not be actually available on the system the application
is going to run under (if it's < 10.7).
So use our own replacements for these functions unless 10.7 was explicitly
chosen as the minimal possible version.
An alternative solution could have been to use weak linking but this is more
difficult and there is no real gain (performance would need to be measured
first).
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74523 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
It was based on a completely erroneous assumption that setlocale() returns the
locale that had been previously active when it actually returns the newly set
locale.
This fixes unit test failures in StringTestCase under OS X, as the locale
wasn't correctly restored by DateTimeTestCase that used this class.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74522 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The m_i field is only used in the currently commented out debugging messages,
suppress a warning about it being unused.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74521 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
