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.
Several new features were implemented in gen_iface.py and accompanying '.in' files:
1. Added an option to parse provisional section in Scintilla.iface. When global variable GENERATE_PROVISIONAL_ITEMS is set to 1, methods and values in this section receive corresponding wxSTC items.
2. Deprecated section in Scintilla.iface is not skipped, but parsed and corresponding wxSTC items are created (marked as deprecated in the code and documentation).
3. Added a set 'notMappedSciValues' that can be used to prevent the creation of specific wxSTC values which are intended to be handled manually.
4. For deprecated constants there is generated a code to raise respective warnings during the compilation.
Closes#17671.
Code to emit PostScript commands to set the current colour is duplicated in several places (in SetBrush, SetPen, DrawAnyText functions) and therefore should be moved to a dedicated function.
Emit code to select PostScript font only if it is needed (not at every call to SetFont(), but only if font has been really changed prior to a text drawing operation).
1. All stuff to generate documentation is moved from 'gen_iface.py' to a separate module 'gen_docs.py'. It contains several new structures to support maintenance of the documentation:
categoriesList - A list of the categories and an optional description.
docsMap - A dictionary that assigns each method to one of the categories.
docOverrides - A dictionary that can be used to replace the docstring from the iface file.
docSubstitutions - A dictionary that can be used to replace a few words from the docstring in the iface file.
extendedDocs - A dictionary that can be used to add extended documentation.
sinceAnnotations - A dictionary that can be used to add '@since' annotations.
2. Documentation is reformatted and updated:
- Added a table of contents.
- Broke the methods into sections.
- Added docs for previously undocumented methods.
- Altered docs that were unhelpful or misleading.
- Added '@since 3.1.0' notes and '@since 3.1.1' notes.
- Altered docs which contained references to Scintilla macros or other problematic text.
Closes#17680.
Generally, Scintilla constants which names beginning with 'SCXX' are mapped to wxSTC names by by stripping out the 'SC' before prepending 'wxSTC_', for example SCWS_INVISIBLE gets mapped to wxSTC_WS_INVISIBLE. Unfortunately, this common rule of mapping the names is not applied to the (legacy) names beginning with 'SCVS_' and 'SCMOD_'.
For the sake of consistency, also these names should conform to the common naming convention, so gen_iface.py is updated to generate conformant names for all affected prefixes. Legacy names are preserved for backward compatibility but commented deprecated and no longer referenced in the documentation.
Closes#17808.
In 68888ca0a2 there were introduced new wxSTC constants representing Scintilla SCTD_* parameters. Unfortunately, their names don't conform to naming convention of other constants and therefore should be changed. For the sake of consistency, Scintilla SCTD_* names should be mapped to wxSTC_TD_* ones.
Closes#17807.
1. Integer instead of floating point arithmetic should be used in calculations.
2. Because this function always returns 2 hexadecimal characters, its parameter type should be changed from 'int' to 'unsigned char' to avoid misunderstandings and prevent misuses.
Closes#12612.
Table of contents is added to the documentation for wxSTC and the brief list of methods is broken into categories corresponding to this table. Documentation of several methods is rearranged and edited.
Closes#17803.
PostScript code to register (and re-encode) given font should be emitted only once. Once registered, the font is available in the entire document and there is no need to register it again.
Add wxCMD_LINE_HIDDEN wxCmdLineParser flag allowing to hide options and/or
parameters.
A hidden/unlisted argument is processed as usual, but not shown in the output
given by Usage(). A use case for such could be diagnostics switches that
should exist but are not useful to the end user.
Closes https://github.com/wxWidgets/wxWidgets/pull/390
