This method seems completely unnecessary, the base
wxTextEntry::DoSetValue(), which delegates to Remove() and WriteText(),
seems to work just as well and avoids code duplication between this
method and wxTextCtrl::WriteText().
Notice that gtk_text_buffer_set_text() is just a trivial wrapper around
gtk_text_buffer_delete() and gtk_text_buffer_insert() anyhow, so there
is no efficiency loss in not using it neither.
Fix compilation/link problems due to symbols redefinitions in user code
that could happen if it included some wx header first, then <windows.h>
(possibly indirectly, e.g. via another third party library) and then
another wx header -- in this case, the second wx header wasn't protected
from <windows.h> redefinitions resulting in all the usual problems.
Avoid this by always including winundef.h whenever any wx header is
included, not just when wx/defs.h is included for the first time.
Get rid of ugly wxDynamicCastThis()s in wxMSW wxControl code and add a
new virtual method overridden in wx{Tree,List}Ctrl instead.
Also stop comparing the font with wxSYS_DEFAULT_GUI_FONT, there doesn't
seem to be any good reason to set this particular font for these
controls neither.
In addition to simplifying and de-ugligying the code, this commit
incidentally fixes -Wnonnull-compare warnings in this code from gcc6
too.
Under MSW calling UnblockAndRegisterWithEventLoop() for blocking sockets
is not only useless, but actually harmful when the socket is used from a
worker thread (which is the common case for blocking sockets), as it
means that the main thread will be receiving notifications for the
socket events and modifying the socket object while it's being used from
the other thread, resulting in data races and general brokenness.
This is similar to e18c8fd29a for Unix
sockets.
Closes#17937.
When WM_ENDSESSION was received by the application, the wxApp object
itself was shut down by calling OnExit() on it before all the TLWs were
destroyed, which could be completely unexpected as during normal
shutdown the order of events is exactly the reverse.
In practice, this resulted in crashes in any application whose main
window close event handler or dtor touched wxTheApp in any way (e.g. to
save any configuration in the global wxConfig object destroyed by
wxApp::OnExit()).
See #9590 (sorry for missing the point before, ATS).
Rewrote wxOSX radio groups-related code reusing the code which works on
wxMSW and which seems to provide more rich functionality (supports adding
radio as well as no-radio items) and to have known bugs fixed.
The ranges of all radio groups are stored in wxMenu itself instead of
storing the information about the radio group an item belongs to in
the item itself - see 89511b4268.
Closes#14213.
Closes#17568.
Apparently various text wrapping modes are not supported natively by
NSTextView (apart from word wrapping which is used by default) and
non-default wrapping has to be implemented in the custom code.
To wrap lines at any character, NSLineBreakByCharWrapping style should be
applied at any text change to the entire text stored in NSTextStorage
associated with NSTextView. This is done in DoUpdateTextStyle() method
which is called from controlTextDidChange() when text is modified by
the user, or SetStringValue() and WriteText() when text is set
programmatically.
This virtual method is implemented in wxWindowBase class only when
wxUSE_DRAG_AND_DROP==1, so it should be re-implemented in the derived class
wxWindowMac also only when wxUSE_DRAG_AND_DROP==1.
wxScopedPtr is referred in wxSVGFileDCImpl declaration, but corresponding
header file is not explicitly included. This can break the compilation if
wxScopedPtr declaration is not included by chance by another module (e.g.
is taken from translation.h but it is not effective when wxUSE_INTL==0).
MakeConfigFileName() is declared as a pure virtual function in the base
class wxStandardPathsBase and has to be implemented in the derived class
wxStandardPaths.
This fixes compilation when wxUSE_STDPATHS==0.
Several functions of wxTextEntry and wxTextCtrl call to
gtk_entry_get_text_length() API to determine the length of the text in
GTKEntry. This API is available since GTK+ 2.14 so we have to implement
a fallback method for older GTK+ versions.
Dedicated function GTKGetEntryTextLength() is implemented in wxTextEntry
and exposed through its interface because it is also used in wxTextCtrl.
Apparently there is no native API to retrieve such information in a simple
way so all calculations have to be done with raw text stored in
the corresponding control(s).
Closes#4146.
See #17811.
The old API didn't make any sense for the most common case when both the
user name and password need to be stored, as it required providing the
user name as input, which couldn't work (but somehow this went
unnoticed for more than a year...).
Fix this by returning the username, and not only the password, from
Load() instead of taking it as parameter and removing this parameter
from Delete() as well.
Also improve the documentation, notably include a simple example of
using this class.
Notice that this is a backwards-incompatible change, but the old API was
really badly broken and didn't appear in 3.1.0 yet, so the breakage is
both unavoidable and, hopefully, shouldn't affect much code.
Nevertheless, a special wxHAS_SECRETSTORE_LOAD_USERNAME symbol is added
to allow testing for it if necessary.
When there is open an editor for some property and in the same time
wxPropertyGrid layout is changed (due to the adding or removing a property,
sorting), it is necessary to recalculate the actual position of the active
editor to display it in the cell dedicated for the edited property. Under
some platforms the position of the edit control is shifted within the cell
and we have to take this shift into account in repositioning process.
Because actual value of the shift depends on the platform and on
the particular control, it is convenient to determine actual shift when
the editor is created and use this value whenever repositioning is done.
Close#17912.
Position of the editor associated with properties like StringProperty,
IntProperty, etc. needs to be adjusted in order to display edited text
at the same position as the text which is displayed as a property value
prior to the editing.
Position of the editor associated with properties like StringProperty,
IntProperty, etc. needs to be adjusted in order to display edited text
string at the same position as the text which is displayed as a property
value prior to the editing.
Don't try to write a general purpose class, but provide just the methods
that we need in our code.
This fixes the bug added in 294436c8bb
which resulted in a crash because a literal string, not a BSTR, was
passed to wxBasicString ctor.
Don't call wxSetlocale() in DoInit() any more, this was redundant when
it was called from Init(wxLanguage) overload.
Add new DoCommonPostInit() called from both Init() overloads after
setting the locale in whichever way they do it to avoid code
duplication.
As a side effect of this change, the error message given if the locale
can't be set is the same now independently of the ctor/Init() overload
used (previously it differed depending on whether a wxLanguage or the
name of the language as string was passed) and it's always logged using
wxLogWarning() and not it in one case and wxLogError() in the other one.
Instead of calling wxLanguageInfo::GetLocaleName(), which called
setlocale() at least thrice (first to query the current locale, second
to try to change it and third to restore the original locale) and then
calling setlocale() again if it succeeded, use the new TrySetLocale()
method which calls setlocale() just once and doesn't require calling it
again in the caller.
This makes the code slightly more efficient but, more importantly,
shorter and more clear.
Re-enable alignment support for wxDataViewCtrl cells in wxOSX which was
previously disabled just to allow the library to compile in 32 bits.
Closes https://github.com/wxWidgets/wxWidgets/pull/377
Define wxCLRDLGG_USE_PREVIEW_WITH_ALPHA as either 0 or 1 instead of using an
expression involving "defined" for it as the latter provoked many clang
-Wexpansion-to-defined warnings, which were harmless but very annoying.
Use underscores on them to show that they are different from properties or
local variables (in pure Objective C they would actually start with
underscores, but this is not a good idea in C++ code) and avoid conflict
between a member name and "wxAlignment" type name, which was confusing.
Instead of disabling vertical alignment support in wxDataViewCtrl, move the
private variables to the header file: this is supported by all versions of the
Objective-C runtime, including the old one used for 32 bit applications,
unlike the new way based on declaring the variable in an anonymous extension.
This replaces the changes of 22216b70e7.
Ensure that the restored size is at least equal to the best size of the
window to avoid cutting off parts of it in (a common) case when a newer
version of the program adds new UI elements, thus increasing the window
best size and possibly making the previously stored size too small.
A simulation of context menu event by handling directly EVT_RIGHT_UP was implemented in wxSTC in 451c5cc7b9, but later on, EVT_CONTEXT_MENU generation in wxOSX was fixed in 524c47aa3a so simulation is no longer necessary and this event can be directly handled in wxSTC.
In order to allow inclusion of configure determined flags via a wx/setup.h include also for xcode builds, the include has to move into the setup0.h template
Don't do it at all in the ctor, initializing just the first element of
the array is useless as it's overwritten by EncodeChar() anyhow, so just
leave the task of NUL-terminating the data to this function as well.
It might be even better to just have a ctor taking wxUniChar in these
classes instead and make EncodeChar() a trivial wrapper around it, but
for now just apply the minimal fix to repair the test breakage after the
last commit.
See https://github.com/wxWidgets/wxWidgets/pull/467#issuecomment-310384946
Don't rely on default array initialization, not only it may not work
with some really old compilers (which is actually not that important as
we don't seem to rely on these arrays being initialized, in fact), but
it results in warnings about working correctly (sic) from MSVC in
versions from 9 up to 12 inclusive.
See https://github.com/wxWidgets/wxWidgets/pull/467#issuecomment-310193867
Rename relatively new enum value wxTASKBAR_JUMP_LIST_DESTIONATION to
wxTASKBAR_JUMP_LIST_DESTINATION as well as a private function containing
the same typo.
This should always the case now, but wasn't when not using configure
(e.g. in MSVC builds) before, so verify this explicitly to ensure that
we don't just silently define wxUSE_UNICODE_UTF16 wrongly, as it
happened before the fix in the previous commit.
* using fontAttributes dictionary allows for better emulation of bold typefaces, also switch to using color from context, this allows keeping the same dict throughout, as a side effect fix font caching
* reverting in order to maintain crossplatform compatibility
* applying review suggestions
* applying review suggestions
* wxGetClipboardData was removed through commit
b375d81499 "Use wxDataObject methods..."
but former usages will break with unreferenced
function as the header still advertises the function
Change-Id: I77e756d2b7d0db7c3833578d2846f4e922a55262
* Add 'wxTextFileType m_fileType' to hold the type
* Add 'wxString m_eol' to hold the end of lines string
* Add SetFileType() and GetFileType() to set and get the type
* Add GetEOL() to get the end of lines wxString
* Backwards compatibility preserved by using wxTextFileType_Unix
Change-Id: I3e8547b377e2c4060a3a2d97c299a08ea2c0a376
Signed-off-by: Adrian DC <radian.dc@gmail.com>
GetPrintDC() should return a new device context created by the print
dialog, not the duplicate of existing context passed from the caller
(e.g. from wxGtkPrinter) through SetPrintDC(). Therefore SetPrintDC() is
no longer useful and can be removed.
Move it out from the auto-generated section to avoid losing it during the next
build/update-setup-h execution (see e24bc249e4
which added this option in the wrong place).
Generic implementation from wxDCImpl doesn't work well with wxPrinterDC
under wxGTK.
(This implementation is adopted from wxCairoContext::GetPartialTextExtents.)
Replace an accidental comma with the semicolon, which is what should have been
used here since the beginning (even though comma actually did do the same
thing).
This was erroneously removed by e82c619402 but
it still needs to be defined here, even if it's not used under macOS, in order
to avoid errors about it being undefined in wx/unix/chkconf.h.
UpdateStyle() function was introduced in edccf428 to synchronize in
SetWindowStyleFlag() style of the control with new style flags just stored
in m_windowStyle.
In 9a8d75f1, storing directly a new flags in m_windowStyle was replaced by
the call to parent's SetWindowStyleFlag().
Because call to parent's SetWindowStyleFlag() updates both m_windowStyle
and actual style of the control for common flags (WS_*, LVS_* flags),
synchronizing the control again with UpdateStyles() is pointless (since
this function does nothing in this context).
Only wxSCROLL style flags need special care because wxListCtrl doesn't
have these styles but the control itself may have them. In order
to preserve them in the call to SetWindowStyleFlag(), we can do the trick
and request the same new scroll style as the actual physical style.
UpdateStyles() is useless now and can be deprecated.
See #17059.
Follow up to 60bd6842e4. Apply equivalent
changes to wxMarkupToAttrString, add a new wxItemMarkupToAttrString
class for mnemonics-less strings and use it in wxDataViewTextRenderer.
IUnknown interface is used sometimes (e.g. in WinRT implementation of
wxNotificationMessage) alone, without other OLE routines, so it is
helpful to have its code in the separate file to avoid coupling with main
OLE code when only IUnknown implementation is required.
WinRT implementation of wxNotificationMessage requires wxUSE_OLE because
one memeber variable is of type wxAutoULong which is defined in the OLE
utilities collection (oleutils.h).
Library itself can be built successfully when wxUSE_DRAG_AND_DROP==1 and
wxUSE_OLE==0 but several wxDropTarget functions (referred in wxWindowMSW,
wxTextDropTarget, wxFileDropTarget) are reported as missing during linking
the application.
Reorganize the code by putting OLE-dependent code into the blocks
controlled by wxUSE_OLE and by sharing remaining code (like implementation
of wxDataFormat, wxBitmapDataObject, wxFileDataObject, etc.) to allow
building wxDataObject and its specializations also without OLE support.
Since wxDataObject no longer requires OLE support, corresponding check in
checkconf.h can be removed.
Thanks to this additional flexibility, it is possible to use wxClipboard
whether OLE support (wxUSE_OLE) is enabled or not, either with OLE-based
wxDataObject (OLE clipboard) or with wxDataObject decoupled from OLE (Win
clipboard API).
wxMetafileDataObject is a specialization of wxDataObject and its
compilation should be controlled directly by wxUSE_DATAOBJ (like it's done
under wxOSX, see e.g. include/wx/osx/metafile.h), not by
wxUSE_DRAG_AND_DROP.
Some wxWindowBase functions were marked deprecated prior to wx 3.0 release
and therefore they should be inserted into WXWIN_COMPATIBILITY_2_8 blocks
to mark them for removal in a future wx version.
Order array cannot be extended both in DoInsertItems() and DoInsertOneItem()
functions because DoInsertOneItem() is invoked indirectly from DoInsertItems()
(through the call to wxCheckListBox::DoInsertItems() and DoInsertItemsInLoop())
and therefore order array would be eventually extended by two items for one
inserted list item. To avoid this duplicated actions, we should resign from
overriding DoInsertOneItem().
In wxRearrangeList implementations (like wxMSW) where DoInsertItemsInLoop()
and DoInsertOneItem() are not used to insert multiple items, DoInsertItems()
has to be overriden to do this insertion.
See #17836.
Number of indices stored in the internal order array has to be the same as
number of the items, so whenever item is added or removed, order array
has to be adjusted accordingly.
Closes#17836.
This method doesn't override any virtual method in the base class, so
wxOVERRIDE can't be used here.
In fact, this method doesn't seem to be used at all, but keep it for
compatibility and in case we want to use it later, as wxGTK does.
No real changes, just use DST_OFFSET constant instead of 3600 and remove the
"FIXME" comments as we're not actually going to fix anything here but will
just continue to assume 1 hour shift for DST.
Since the changes of c9a458bfe8 ("Use Win32
::CommandLineToArgvW() to tokenize command line"), this is not guaranteed any
more as this Win32 function doesn't necessarily ensure it under older MSW
versions such as XP.
Just use "argc" explicitly instead of relying on this in wxCmdLineArgsArray to
fix crashing under XP.
Handle "&" in exactly the same way as "&" in wxMarkupParser, i.e. do not
map the former to "&&" to prevent it from being interpreted as a mnemonic as
this is incompatible with using markup for anything but the control labels,
e.g. for wxDataViewCtrl items text, in which mnemonics are not recognized.
And even when using markup for control labels, it was a questionable decision
as it's really not clear at all why should the XML entity and the raw
character itself be handled differently.
Also split wxMarkupText into two classes, wxMarkupText that handles
mnemonics in the markup (which is typically a label) and a very
similar, but not derived, wxItemMarkupText that handles mnemonics-less
markup for list etc. items, uses DrawItemText() and supports
ellipsizing.
Illustrate the use of ampersands in the dataview sample.
This method is only used, and defined, when using rich edit controls, so don't
declare it if wxUSE_RICHEDIT==0.
This should fix a link error in this build variant.
Closes https://github.com/wxWidgets/wxWidgets/pull/452
Assert and return false instead, this is more developer-friendly.
Add unit tests to check that these functions really work as expected when
called on a closed file.
Closes#17828.
This makes sense and avoids an error if some other header sabotages our
__has_warning definition check by providing a dummy definition for it (as ICU
does, for whatever reason).
While we use wmain() for the compilers that provide it since the changes of
bfa78c63b9, we still didn't handle Unicode
command line arguments not representable in the current Windows code page
correctly when using other compilers (e.g. MinGW).
Now use Win32 ::GetCommandLine() function for them and parse the command line
ourselves instead of relying on non-Unicode-friendly main() arguments which
can't represent arbitrary Unicode strings when not using UTF-8 (which is never
the case under Windows).
Use an enum instead of type-unsafe "int" for the second parameter of the
recently added wxStandardPaths::MakeConfigFileName().
This also avoids unnatural dependency of wxStandardPaths on
wxCONFIG_USE_SUBDIR constant defined in a higher level wxFileConfig class.
No real changes, but just make things a bit more robust and hopefully more
clear.
Slight improvement to the previous commit: make FileLayout_Classic and
FileLayout_XDG elements of an enum instead of using an untyped "int" for them
which didn't really make any sense because these values are not bit masks but
exclusive choices for the layout.
Also rewrite the checks for them to use "switch" instead of "if" to be warned
by the compiler if we ever add another enum value but forget to update the
code to handle it.
Finally, improve the documentation (add missing "@since") and comments.
