This still doesn't work if the file doesn't exist, but at least shows
the correct file name if it does exist, which is better than nothing and
the best we can reasonably do when using the native control.
Closes#19163.
This comes at the price of breaking compatibility and returning
"\\share" rather than just "share" from wxFileName::GetVolume() for the
UNC paths. This breakage seems justified because it is required in order
to allow application code to distinguish between paths "x:\foo" and
"\\x\foo", which was previously impossible as GetVolume() returned just
"x" in both cases.
Document this change, adjust the existing checks for the new GetVolume()
semantics and add a new test which passes now, but didn't pass before.
Closes#19255.
This commit is best viewed ignoring whitespace-only changes.
Replace the workaround introduced as a "temporary fix to avoid breaking
backwards compatibility in 2.8" back in 9e1c7236e0 (don't treat foo in
c:\\foo\bar as network share, 2006-12-17) with a better solution
proposed in the comment in that commit, i.e. don't even try to extract
the volume from the path if we already have the volume separately.
This commit is best viewed ignoring whitespace-only changes.
Creating a directory with the leading path separator unexpectedly
created it under the current directory rather than in the root of the
current drive under MSW, due to the path being considered relative, in
spite of starting with the path separator, because it didn't have the
volume.
Fix this by avoiding the use of IsAbsolute() in Mkdir() and checking for
m_relative instead, as it seems the safest possible fix for this bug
because changing IsAbsolute() to return true in this case might change
the behaviour of the existing code.
Closes#4470.
Extend the existing workaround to work not only with explicitly
wxPATH_DOS paths, but with paths implicitly using the DOS format due to
it being the default format for the current platform.
Closes#19261.
Add wxComboCtrl::SetMainControl() which can be used to use some other
window instead of the default wxTextCtrl as the main window of the
combo control.
Update the sample and the documentation to show the new function.
There doesn't seem to be any point in using local "customBorder" instead
of member "m_widthCustomBorder", so remove the unnecessary local
variable and use the member variable instead.
No real changes.
Don't set default width every time the column is updated, as it happens
e.g. when it's clicked by the user, but only when it is created, by
moving the code added in 96d36383bd (Use sensible default column width
in generic wxListCtrl too, 2021-08-17) from SetItem() to the ctor of
wxListHeaderData.
Closes#19256.
Initialize m_ribbonBar added in the previous commit to NULL before
setting it to the correct value later, when wxRibbonButtonBar is fully
created.
See #19249.
Co-Authored-By: Maarten Bent <MaartenBent@users.noreply.github.com>
Fix crash introduced by 8e8a68c1b (Move code accessing bitmaps to
wxRibbonButtonBarButtonBase too, 2020-02-07) which start using
GetAncestorRibbonBar() in wxRibbonButtonBar code, without taking into
account that we may have no ribbon bar ancestor when the button bar is
shown in a popup frame, as it happens when there is not enough space to
show it fully in the main window itself.
Remember the ribbon bar in a member variable, relying on the fact that
we must have it in our parent chain when constructed, and just use it
later to avoid this.
Closes#19249.
There doesn't seem to be any reason to disallow copying these objects
and because they only have const methods, we can use reference counting
for them without bothering with copy-on-write, so it's simple to
implement.
This static function parses a subset of the language tags described in
BCP 47 (see https://www.rfc-editor.org/rfc/bcp/bcp47.txt).
Use the tag, as specified by this function, rather than the locale
identifiers components under MSW, where this should allow us to use even
locales that can't be described using just language-script-region.
We don't use empty wxLocaleIdent as default user locale and it doesn't
make much sense to do it, as the default locale is already accessible
via wxUILocale::GetDefault().
No real changes, just don't make all wxLocaleIdent setters inline, this
is not necessary as none of these methods are performance-critical.
This commit is best viewed with --color-moved git option.
Use wxUIntPtr rather than (unsigned) long in wxImage::ResampleNearest()
as long is still 32 bits under Win64 and so doesn't allow the code there
to work with images larger than 2^16 in either direction, when it could
be allowed in this case.
Document the current limits on the size of the image and add a unit test
checking that resizing images of size greater than 2^16 works in 64 bits.
See #18550.
No real changes, just move this class declaration as it seems more
logical to have it in the same header with wxUILocale which is the only
place where it's used.
This commit is best viewed with --color-moved git option.
Do this for consistency with the other ports and because this seems more
useful anyhow.
Update the documentation to make this behaviour more clear and document
this change as a (minor) incompatibility in wxMSW.
Also add more unit tests to check for this behaviour. Note this also
fixes the problem with the unit test added in the grandparent commit
under MSW.
This is explicitly allowed and we even have a unit test checking for
this, but the test crashed under macOS.
Fix this by simply doing nothing in wxWindow::DoEnable() if the window
is not created yet.
Just return NULL from this (wxOSX private, in spite of not using a
port-specific prefix) method.
This fixes crash in wxButton::SetBitmapXXX(wxNullBitmap), as shown by
the new test case which used to crash but doesn't do it any longer.
Closes#19257.
Save initial affine transformations for just created CGContext
(like it's done in all wxMacCoreGraphicsContext ctors) to properly
manage user-defined transformations in SetTransform(),
GetTransform().
This is done to fix the build error in STL builds after the previous
commit, as using Find() or DeleteObject() with a pointer of the "base
type" worked when using wxWindowList in the default build, but not in
the STL build, so this commit avoids this mismatch by allowing to use a
base class pointer where it is safe to do so, i.e. where it can be done
without a downcast, as there doesn't seem to be any reason to have this
difference between the builds in this case.
Note that there is still a difference between Append() and Insert()
methods which (correctly) require the pointer of right type in STL build
but still accept a pointer of the base type in the default build for
compatibility reasons.
In particular, this means that one of the casts removed in the last
commit from wxWindowBase code needs to be restored, as Append() still
requires a wxWindow and not just a wxWindowBase.
This list uses wxWindowBase for its elements, so downcasts are
unnecessary and actually harmful as the downcast performed in the dtor
results in undefined behaviour because the object is not a wxWindow any
more by then (thanks to UBSAN for detecting this).
We need to use [NSString compare:options:range:locale:], as there is no
corresponding CFString function, so use NSLocale functions rather than
CFLocale ones too, for consistency.
No real changes.
Unlike MSW and macOS, creating wxUILocale for e.g. "en" doesn't
necessarily succeed under Linux even if "en_US" is available, so try to
find a working language+region combination if just language doesn't
work.
This requires access to the languages database, so add a private
wxGetLanguageInfos() to avoid having to depend on wxLocale just for
this.
There is no reason to use the macro-based classes for this array as
there are no compatibility constraints here, so use a simple vector
instead.
Note that we need an extra boolean variable now that we don't use a
pointer because we can't just check whether the vector is empty, as this
would return in infinite recursion when InitLanguagesDB() calls
AddLanguage() which, in turn, calls CreateLanguagesDB().
This is required for wxLocale compatibility, as using wxLANGUAGE_ENGLISH
is supposed to be the same as using "C" locale (even if it isn't,
really) at wxLocale level.
This function can now be implemented relatively straightforwardly
(although it does require an extra check under Mac), so add it, as it
can be generally useful and we're also going to need it for our own
tests in the upcoming commit.
This finally seems better than always creating some kind of impl object,
even if the locale isn't supported at all and makes all ports behave
consistently, as previously CreateForLocale() only returned NULL in
wxOSX implementation if the locale was unrecognized, but now all ports
do this (at least when locale_t and related functions are available
under Unix).
Also stop returning bool from Use(), as this resulted in initializing
wxLocale with any non-default language to fail under Mac: just ignore
the error here, as we always did it until now, because there is nothing
we can do about it anyhow.
Extract it from existing MSW-only code and make it available in all
ports so that we could use it as a fallback in wxUILocale if everything
else fails.
No real changes yet.
This required changing CompareStrings() to be a method of wxUILocale
object, rather than just as a static function, as we must only allocate
the locale_t object once, and not during each to this function, as this
could make it unusably slow when using it as a comparison function when
sorting a large list of strings.
This is also more efficient under Mac, where we can similarly allocate
NSLocale only once and even marginally more efficient under MSW, where
we don't have to construct the locale string during each call. And,
under all platforms, it also simplifies code by separating this function
implementation from the initialization of wxUILocaleImpl.
Also document that case-insensitive comparison is not available under
Unix and adjust the tests accordingly.
