Simplify things by putting setup.h files themselves under version
control and getting rid of setup0.h ones.
The initial motivation for using separate setup0.h files was to allow
having local changes to setup.h, but with Git there is a simple way to
do it by using "git update-index --skip-worktree include/wx/msw/setup.h"
for example, so we don't really need setup0.h any more and dropping them
makes things simpler.
Remove automatic definition of wxUSE_WEBREQUEST depending on whether
wxUSE_WEBREQUEST_XXX are defined and follow the same approach as with
wxUSE_GRAPHICS_XXX, i.e. define wxUSE_WEBREQUEST_XXX as wxUSE_WEBREQUEST
by default instead.
Move wxUSE_WEBREQUEST_WINHTTP to wxMSW-specific file, it doesn't need to
be in common one (unfortunately this can't be done for the Mac-specific
wxUSE_WEBREQUEST_URLSESSION yet, because macOS-specific settings are not
injected into setup.h.in currently).
Also fix test for winhttp.h availability: it seems to be present in all
MinGW64 distributions, but not in MinGW32, so test for this and not for
gcc version.
Finally remove the now unnecessary test for macOS 10.9, as we only
support 10.10+ anyhow by now.
This requires refactoring NewCloseButton() in order to extract
CreateCloseButton() from it, as XRC relies on being able to use two-step
creation which was previously impossible for this kind of buttons.
CreateCloseButton() is rather unusual, as it has to be declared in the
derived, platform-specific class, in order to be able to call its
Create(), but is defined only once in common, platform-independent,
code. However the only alternative seems to be to have a static
function, e.g. InitCloseButton(), which wouldn't be very pretty neither.
Closes https://github.com/wxWidgets/wxWidgets/pull/2118
Use a dirty hack to accommodate wxUniv by deriving wxRadioButtonBase
from wxCheckBox, rather than wxControl, there. This is not pretty, but
should be addressed by refactoring wxUniv code and in the meanwhile all
the other ports don't have to bother with using a template class
unnecessarily.
Now that we do have wxRadioButtonBase class, declare wxRadioButton API
methods as pure virtual in it, to force the derived classes to implement
them.
Also remove the outdated comment saying that there is no base class for
wxRadioButtons in different ports, this is not true any longer.
Apply the utility from https://github.com/codespell-project/codespell/
to fix spelling issues in the headers under both include and interface
directories and add a file with a couple of exceptions.
The exact command line used was:
$ codespell -w -I misc/scripts/codespell.ignore -i 3 in*
Instead of checking for all text-like controls one by one in
wxCommandEvent::GetString(), call a virtual function checking for this.
This is simpler, less error-prone and faster -- at the cost of
increasing the vtbl size of all wxWindow-derived classes.
Closes https://github.com/wxWidgets/wxWidgets/pull/1696
It defaults to 1, but can be set to 0 to force using the generic version
of the control even under GTK or Mac, where the native version is used
by default.
This can, unfortunately, be useful to work around various but multiple
native control limitations.
This could result in infinite recursion in wxX11, as the test for the
new size being different from the old one which was supposed to stop the
recursion, failed there in case the new size was 0: as wxX11 can't use 0
size for the window, the actual size was always different and so we kept
sending size events to the parent, which kept resizing the toolbar etc.
It could be argued that there is a bug in wxX11 and that GetSize() must
return the same value as was passed to SetSize(), even if it was 0, and
this might even be correct, in theory, but it doesn't seem worth to do
it just to accommodate this weird use case, especially because resizing
the parent from the child shouldn't be necessary in the first place and
none of wxToolBar implementations in the other ports does it.
So just remove this code completely.
Closes#18554.
This is not really an option as building requires it to be 1, so don't
make it one in setup.h/configure/cmake and just hardcode it as 1 for
compatibility.
Closes#18558.
This is always 0 for any still supported compiler, so remove the option
and configure checks for it.
Still define it as 0 for compatibility, just in case it's used outside
of the library.
The names of these methods were confusing because they implied that they
were the actual implementations of the public [SG]etLabel(), while this
wasn't at all the case.
Give them then ames describing what they really do and also update the
comments to hopefully be more clear.
No real changes.
Including <winsock.h> and <winsock2.h> is incompatible and if the
application wants to use the latter, it may be convenient to define
wxUSE_WINSOCK2 when building wxWidgets instead of having to work around
winsock.h implicit inclusion from include/wx/msw/wrapwin.h.
Closes https://github.com/wxWidgets/wxWidgets/pull/1122
Prompting for user name and password is a common task.
At least windows provides these dialogs native but this
is just a generic implementation for now.
Prepare for using liblzma in wxWidgets code by adding the necessary
option and updating the configure check for it (which had been already
present due to libtiff possible dependency on liblzma).
No real changes yet.
It seems that MinGW-w32 started distributing GDI+ headers since this
version and MinGW-w64 might have supported them for even longer, but
it's difficult to test for the MinGW distribution used in this header,
as it is included before wx/msw/gccpriv.h which defines
__MINGW32_TOOLCHAIN__ and __MINGW64_TOOLCHAIN__ symbols and changing
this is tricky due to relative order of defining UNICODE and
wxUSE_UNICODE and including MinGW headers, which can only be included
once UNICODE is set properly.
But while the fully correct solution is difficult, just checking for the
compiler version should solve the problem in 99.99% of the cases in
practice as there should be vanishingly few people using MinGW-w64 with
gcc < 4.8 currently, so this simple solution is good enough.
Closes#17973.
Handle this feature as all the other ones and provide a configure switch
and a setup.h option to disable it if necessary, as it may be desirable
to do it, especially under Linux, to avoid extra dependency on pangoft2
if this functionality is unnecessary.
While we have to keep these conversions enabled by default, they are very
dangerous as they can result in silent data loss on any system not using a
locale with UTF-8 encoding, i.e. always under MSW.
Allow mitigating this by defining wxNO_UNSAFE_WXSTRING_CONV when compiling the
application code using the library, which makes these conversions invisible to
the user code, and so can be used without recompiling the library.
Also add wxUSE_UNSAFE_WXSTRING_CONV which can be set to 0 when compiling the
library to disable these conversions globally for all applications using it.
Closes#11830.
Propagate the change done in 49000defcf to the
generated include/wx/msw/setup0.h file to wx/setup_inc.h, so that this change
won't be lost during future regenerations.
Compile accessibility support on Windows by default now that the generic
wxDataViewCtrl control implements accessible interface. After the
changes from 7dab555f71, accessibility
support is much more lightweight and doesn't interfere with normal win32
behavior, so this change shouldn't affect accessibility-unaware code in
any way.
Add a new class allowing to store passwords and other sensitive information
using the OS-provided facilities.
Add implementations for all the main platforms, documentation and a new sample
(which contains an ad hoc unit test as the real unit test for this class would
probably be a bad idea as it wouldn't run in non-interactive contexts and
could show OS level dialog boxes if it did).
This warning was given many times and was very confusing as it wasn't given at
all in the right location, but rather for all the other, subsequent
declarations of wxControlRenderer which were correct -- unlike this one which
used wrong order for the "class" keyword and the attribute.
This symbol was wrongly added to include/wx/msw/setup0.h directly in
075ef6551e, so it didn't work when
cross-compiling from Unix (which doesn't use this file) and would have been
lost after any future modification of include/wx/setup_inc.h where it should
have been added in the first place.
Do this now and also make the check for this symbol in wx/progdlg.h a bit more
readable.
This is a simple animated control indicating some program activity.
Provide native GTK+ (for > 2.20) and OS X implementations as well as a generic
one used under MSW.
Update the sample and the documentation.
This is a simple high level helper combining an arbitrary control showing
multiple items with the buttons allowing to add items to and remove items from
this control, but using the buttons and the layout appropriate for the current
platform.
Add the implementation itself, an example of using it to the dialogs sample
and the documentation.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78462 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This didn't do (almost) anything, so just remove it, using MFC and wxWidgets
together works just fine without it.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78277 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This option, which is on by default unless the use of STL is disabled,
provides better interoperability with the standard library when it can be done
without breaking backwards compatibility.
The first example of its use is to allow passing std::vector<> of any string
compatible type to wxItemContainer::Append(), Insert() and Set(), allowing to
directly initialize various wxControls deriving from it such as wxChoice,
wxComboBox, wxListBox from a std::vector<> of strings.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78066 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
