Contrary to the comment in wxHtmlHelpFrame::Create(), this doesn't seem to be
necessary and can be actually problematic.
Never adding this menu obviates the need for the wxHF_MENU style from #15538.
Closes#15538.
It's confusing that wxLogInfo() and wxLogVerbose() are exactly the same and
the former, and not only the latter, doesn't do anything unless SetVerbose()
had been called, even if the log level is wxLOG_Info or higher.
Fix this by checking for GetVerbose() in wxLogVerbose() only and making
wxLogInfo() check the log level only. This makes it very similar to
wxLogMessage() but this is not such a bad thing.
Also improve wxLogVerbose() documentation.
Update misc/scripts/inc_release script: remove non-existent any more files and
update the version in the MSVS 200x project files not generated by bakefile
any more and MSVS 201x project files which were not previously taken into
account.
Run it and rebake.
Add GetOSMicroVersion and add other micro version references in an
unobtrusive way: don't change wxPlatformInfo's constructor and use
default parameters for CheckOSVersion and SetOSVersion. The only change
that could affect user code is the changed number of parameters for
DoCheckVersion but because that is a protected function it's less likely
to be a problem.
In addition to getting a major and minor OS version allow a micro
version to be retrieved. In case of running on e.g. OS X 10.10.3 this
allows the "3" to be retrieved again.
Previously the editor created by wxDataViewRenderer::CreateEditorCtrl() had to
be a native GTK+ widget implementing GtkCellEditable interface which prevented
using composite windows (e.g. a container for a text control and a button) as
editors.
Create a helper container wrapping them now and implementing GtkCellEditable
now to allow this.
Since the changes of 8034e35391 (see #16870)
accelerators, including the standard ones such as Ctrl-F4 under MSW, didn't
work any longer inside the MDI children.
Fix this by extending IsTopNavigationDomain() to allow for checking whether
the given window should stop propagation of all keyboard events, as wxTLW
does, or only TAB navigation ones as wxMDIChildFrame and wxAuiFloatingFrame
do.
Exporting these classes doesn't seem necessary as they only have inline
functions and doing it results in problems with MSVC as it also, apparently,
exports the corresponding specialization of std::vector<T> from the wxWidgets
DLLs which can clash with the use of std::vector<T> in the user code or even
in 3rd party libraries included in wx itself, such as Scintilla, so this
change fixes link errors in "DLL Debug" build configuration when using MSVC.
Closes#10884.
Using the library wasn't really possible with all the debug messages it
generated, so either suppress them completely or turn them into trace messages
which can be activated on demand if needed.
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.
Add wxGLAttribsBase, wxGLAttributes and wxGLContextAttrs replacing the old
untyped "int attributes[]".
Don't use global object for creating OpenGL > 3.0 contexts.
Closes#16909.
We reuse the same global dispatcher object (allocated in
wxFDIODispatcher::Get()) for the sockets created in different threads, so it's
perfectly possible for its methods to be called concurrently and this happens
even in our own socket streams unit tests.
Protect against concurrent modification of the select sets and m_maxFD. This
fixes sporadic Travis build failures such as the one at
https://travis-ci.org/wxWidgets/wxWidgets/jobs/110757281 for example and
probably even worse bugs too.
No real changes, just some cleanup to ensure that the item being edited stored
in wxDataViewRendererBase never refers to an item which is not, actually,
being edited any longer.
Reuse the same code from the generic and native GTK and OS X implementations
of wxDataViewCtrl instead of triplicating it.
This fixes a small discrepancy between the wxOSX version, which didn't see the
model pointer correctly in the generated event, and all the others, but mainly
paves way for future improvements.
This will make it possible to reproduce the default "Enter" key functionality
from elsewhere.
Almost no changes yet, the only minor change is that we now wouldn't try to
"click" any windows using DLGC_DEFPUSHBUTTON dialog code but which are not
really buttons -- but then this shouldn't ever happen anyhow.
Override newer and more flexible virtual method: this doesn't change anything
yet but will allow to provide default handling for some messages in a single
overridden method in the future commits, when it would have required to also
override MSWDefWindowProc() with the old method.
This is never going to work, so complain about trying to do it to help with
catching this bug.
This is possible thanks to the new OnDynamicBind() method invoked whenever a
dynamic event handler is bound to a control, so this doesn't detect all
possible occurrences of the bug (such as specifying the handler in a static
event table or in a validator), but it's still better than nothing.
In the future OnDynamicBind() should be extended for other invalid calls, e.g.
binding a handler for wxEVT_TEXT_ENTER to a non-text control shouldn't work
neither, ideally.
These functions were almost but not quite identical to it:
wxSafeConvertMB2WX() tried the current locale encoding before UTF-8 while
wxConvWhateverWorks tries UTF-8 first and then the current locale encoding.
The latter behaviour is more correct as valid UTF-8 could be misinterpreted as
some legacy multibyte encoding otherwise, so get rid of this difference and
just forward these functions to wxConvWhateverWorks.
This ensures that we can create output files with Unicode names even when
they're not representable in the current locale encoding, notably when the
current locale has never been changed and is still the default "C" one, not
supporting anything else other than 7 bit ASCII.
Credits for the new class name go to Woody Allen.
If a class not using "override" for its other, not wx-related, virtual methods
included wxDECLARE_EVENT_TABLE() with wxOVERRIDE inside it, it resulted in a
clang -Winconsistent-missing-override warning per each virtual method without
it which was very annoying.
Avoid it by not using wxOVERRIDE in this macro and explicitly disabling the
-Winconsistent-missing-override for the methods inside it in case the rest of
the class does use "override".
Notice that this also required rearranging the order of the declarations in
this macro to ensure that a semicolon is still required after it.
Closes https://github.com/wxWidgets/wxWidgets/pull/217
