wxFloatingPointValidator and wxIntegerValidator copy ctor didn't copy
the associated window, so it was lost when the validator was Clone()'d.
Fix this by correctly using wxValidator copy ctor, instead of the
default one, in the copy ctor of the common wxNumValidatorBase base
class.
Avoid problems when using this header in code also include <windows.h>
(and not doing it via wx/msw/wrapwin.h) by ensuring that min and max
used here are not defined as macros.
We need to explicitly generate this event from the char hook handler as
we don't get the normal WM_CHAR for it, it is apparently intercepted by
the window proc installed by the auto-completing code, so check if
wxTE_PROCESS_ENTER is used for the text entry and call a special new
MSWProcessSpecialKey() method to do the right thing if it is.
Similarly, handle Tab presses correctly if wxTE_PROCESS_TAB is used.
Closes#12613.
Inherit from wxCompositeWindowSettersOnly<> to make sure all the usual
setters, such as SetForegroundColour() and SetFont(), called on
wxStaticBox are propagated to the label window too.
However also prevent SetBackgroundColour() from being propagated
unnecessarily -- because the checkbox already inherits the parent
background colour by default in wxMSW anyhow -- and still override
SetFont() to adjust the label window position after the font change,
otherwise it could be truncated after increasing the font size, for
example.
Because of these issues, wxCompositeWindowSettersOnly is not ideally
suited for its use here, but on balance it still seems to be better to
use it rather than reimplement parts of its functionality here.
Extract this class from wxCompositeWindow, as sometimes it can be
convenient to just define the setter functions to do the right thing for
a window containing sub-windows, but without dealing with focus too.
This will be used in wxMSW wxStaticBox in the next commit.
As this class is only supposed to be used as a base class, its ctor
doesn't need to be, and hence ought not to be, public.
Also update an outdated comment stating that the ctor didn't do anything
when it, in fact, does perform an important task.
Remove wxSIZE_AUTO from the SetSize() call, this was completely
unnecessary and unexpectedly (and wrongly) resized composite windows
managed by sizers as SetLayoutDirection() side-effect.
This allows to call the protected wxWindowGTK::DoApplyWidgetStyle()
method when it's really necessary, e.g. when forwarding to it from
DoApplyWidgetStyle() implementation for another window.
Factor out the code from wxStaticBoxSizer dtor into a wxStaticBox method
to improve encapsulation: the static box knows better than another class
how to detach its children from it before destroying it.
No real changes yet.
MSVS 2017 (which uses _MSC_VER from 1910 to 1912 currently) is
ABI-compatible with MSVS 2015 (_MSC_VER 1900), so do allow linking code
compiled with one of them with the library built by the other one.
Closes#18024.
When using two-step creation, as when loading from resources, for
example, it can be convenient to create wxMFCWnd as part of the (parent)
wxWindow object, but only attach it to the real HWND later, once it
becomes available.
This avoids using m_pMainWnd after its HWND becomes invalid, as this
resulted in assert failures from CWnd::WalkPreTranslateTree() called
with this HWND as its hWndStop argument from PreTranslateMessage() which
was used to pre-translate a WM_NULL message the application sometimes
received while closing down.
Still use the active event loop if there is one, just in case it
customizes messages pre-processing, but fall back on the standard
pre-processing code even if there is no active wx event loop and we're
only running the MFC one, as without doing this there are just too many
things that don't work (e.g. menu accelerators didn't work at all in
mixed wx/MFC applications previously).
When porting an existing MFC codebase to wxWidgets, it may be useful to
continue using the existing CWinApp-derived application class, so allow
deriving wxMFCApp from it instead of always deriving it from CWinApp
itself.
This can be used in order to use normal Unicode build of wxWidgets with
an application that needs to use ANSI versions of Win32 functions, e.g.
because it doesn't compile with UNICODE defined.
Allow reusing this functionality from outside the library, it can he
useful if an MFC window needs to be embedded into a wx application (or
vice versa).
Also use a better wxEntryStart() overload as a side effect, this should,
in particular, fix the problem with command line arguments processing in
mixed MFC/wx applications pointed out in a comment in the sample
previously.
Do not use 'RADIO_SIZE 20' as the fixed width of the radio button, but use the actual width as returned by wxRendererNative.
wxRendererNative has no GetRadioButtonSize, so for now use GetCheckBoxSize. It returns the same sizes.
Also add a half character width to account for the space between the button and the label.
There is no need to add extra width to the label of the static box.
Closes#18010.
Add wxMSWWinStyleUpdater and wxMSWWinExStyleUpdater helper classes which
allow writing code changing GWL_STYLE and GWL_EXSTYLE bits,
respectively, in a shorter and more clear way.
There should be no real changes in behaviour.
Replace the hack with resizing the control to the minimal possible size
while it's frozen with just disabling its scrollbars in the frozen
state. This should also fix the original problem (of scrollbar jumping
around wildly as the items are added), but without different problems
due to the control being resized unexpectedly.
Unfortunately we don't have a reproducer for the original problem, which
the commits 6754c300cf ("Freeze wxTreeCtrl
in wxMSW by hiding it") and 4e1e8dc51b
("Change wxMSW wxTreeCtrl::DoFreeze() to not hide the tree any more" --
but resize it instead) tried to fix, so it's difficult to be sure that
it really doesn't exist any more, but it does seem like it ought to be
as the comment added back then spoke of the problem with scrollbar
updating and this really shouldn't happen if scrollbars are completely
disabled.
See https://github.com/wxWidgets/wxWidgets/pull/375
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.
Fix a copy-and-pasto in the header and also mention that wxURLDataObject
derives from wxDataObjectComposite, and not wxTextDataObject, in wxGTK
too.
Also add a note about the exact base class being an implementation
detail.
Closes https://github.com/wxWidgets/wxWidgets/pull/624
This is more convenient and less error prone than using the existing
ctor taking char pointer and length as the buffer contains both.
Also add the corresponding assign() overload for consistency.
See #16490.
Show non-printable characters when comparing strings more clearly if the
comparison fails, this is notably useful for strings containing NULs as
they were previously completely lost.
Miscellaneous fixes for time zones and DST handling in wxDateTime.
This still leaves 2 big problems:
1. We have no support for using the correct time zone offset at the
given date and always use the current time zone offset, which may,
and often is, wrong.
2. Our code for converting to/from broken down representation doesn't
handle DST at all, so support for DST is non-existent for the dates
before 1970-01-01 or after 2038-01-01 (i.e. roughly outside of the
32 bit time_t range).
See #10445 and the other tickets linked from there.
Don't rely on time zone offset to check whether it is local as this
doesn't, and can't, work for the local time zone in Great Britain which
uses the same offset as UTC, but does use DST, unlike the latter.
Add a unit test (albeit disabled by default) checking that the code that
previously didn't work correctly in BST does work now (run the tests
using "TZ=Europe/London ./test wxDateTime-BST-bugs" under Unix to test).
Closes#14317, #17220.
See #10445.
The class needs to use WXDLLIMPEXP_ADV in order for its (default,
compiler-generated) dtor to be generated inside the library, otherwise
this doesn't happen and linking code using this class inside a shared
library fails with errors due to the dtor being undefined.
This is a tiny optimization (or maybe not so tiny on platforms other
than Linux where time() might not as fast as just reading a memory
location), but mostly is done to work around faketime bug[*] which
prevented it from being used for testing programs using wxWidgets, such
as our own unit tests because time() was called from wxLogTrace() in
wxCSConv::DoCreate() called when creating global conversion objects
during the library initialization.
Arguably, it might be better to avoid calling wxLogTrace() during the
initialization, but this can't be done as simply and this change might
have a small performance benefit too.
[*] https://github.com/wolfcw/libfaketime/issues/132
