| Age | Commit message (Collapse) | Author |
|---|
|
|
|
mail drop does not have any outstanding events.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The installer is (once again) running with Admin privilege elevation even for
a Standard Windows user, so it can't determine the underlying Standard user.
Therefore it can't clean up any per-user shortcuts left over for that Standard
user. Moved the kludge to SLVersionChecker.
|
|
|
|
|
|
|
|
|
|
But since that viewer-manager build depends on being able to read the
application name from build_data.json (to locate the shortcut), add an AppName
key to build_data.json.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
instead of a variable of type decltype(expression).
Using SHGetKnownFolderPath(FOLDERID_Fonts) in LLFontGL::getFontPathSystem()
requires new Windows #include files.
A variable with a constructor can't be declared within the braces of a switch
statement, even outside any of its case clauses.
|
|
|
|
Use LLStringUtil::getenv() or getoptenv() whenever we fetch a string that will
be used as a pathname.
Use LLFile::tmpdir() instead of getenv("TEMP").
As an added extra-special bonus, finally clean up $TMP/llcontrol-test-zzzzzz
directories that have been accumulating every time we run a local build!
|
|
Move Windows-flavored llstring_getoptenv() to Windows-specific section of
llstring.cpp.
boost::optional type must be stated explicitly to initialize with a value.
On platforms where llwchar is the same as wchar_t, LLWString is the same as
std::wstring, so ll_convert specializations for std::wstring would duplicate
those for LLWString. Defend against that.
The compilers we use don't like 'return condition? { expr } : {}', in which we
hope to construct and return an instance of the declared return type without
having to restate the type. It works to use an explicit 'if' statement.
|
|
Add ll_convert<TO, FROM> template, used as (e.g.):
ll_convert<std::string>(value_of_some_other_string_type);
There is no generic template implementation -- the template exists solely to
provide generic aliases for a bewildering family of llstring.h string-
conversion functions with highly-specific names. There's a generic
implementation, though, for the degenerate case where FROM and TO are
identical.
Add ll_convert<> specialization aliases for most of the string-conversion
functions declared in llstring.h, including the Windows-specific ones
involving llutf16string and std::wstring.
Add a mini-lecture in llstring.h about appropriate use of string types on
Windows.
Add LL_WCHAR_T_NATIVE llpreprocessor.h macro so we can detect whether to
provide separate conversions for llutf16string and std::wstring, or whether
those would collide because the types are identical.
Add inline ll_convert_wide_to_string(const std::wstring&) overloads so caller
isn't required to call arg.c_str(), which naturally permits an ll_convert
alias.
Add ll_convert_wide_to_wstring(), ll_convert_wstring_to_wide() as placeholders
for converting between Windows std::wstring and Linden LLWString, with
corresponding ll_convert aliases. We don't yet have library code to perform
such conversions officially; for now, just copy characters.
Add LLStringUtil::getenv(key) and getoptenv(key) functions. The latter returns
boost::optional<string_type> in case the caller needs to detect absence of a
given environment variable rather than simply accepting a default value.
Naturally getenv(), which accepts a default, is implemented using getoptenv().
getoptenv(), in turn, is implemented using an underlying llstring_getoptenv().
On Windows, llstring_getoptenv() returns boost::optional<std::wstring> (based
on GetEnvironmentVariableW()), whereas elsewhere, llstring_getoptenv() returns
boost::optional<std::string> (based on classic Posix getenv()).
The beauty of generic ll_convert is that the portable LLStringUtilBase<T>::
getoptenv() template can call the platform-specific llstring_getoptenv() and
transparently perform whatever conversion is necessary to return the desired
string_type.
Add windows_message<T>(error) template, with an overload that implicitly calls
GetLastError(). We provide a single concrete windows_message<std::wstring>()
implementation because that's what we get from Windows FormatMessageW() --
everything else is a generic conversion to the desired target string type.
This obviates llprocess.cpp's previous WindowsErrorString() implementation --
reimplement using windows_message<std::string>().
|
|
|
|
|
|
Instead of returning a wchar_t* and requiring the caller to delete it later,
return a std::basic_string<wchar_t> that's self-cleaning. If the caller wants
a wchar_t*, s/he can call c_str() on the returned string.
Default the code_page parameter to CP_UTF8, since we try to be really
consistent about using UTF-8 encoding for all our internal std::strings.
|
|
|
|
The previous build declared a static std::ofstream; but the code that
determines the pathname for the log file is called so early that static
objects have not yet been constructed. Declare a pointer instead, and
instantiate it on demand.
|
|
|
|
|
|
|
|
|
|
This logic is essentially copy-and-edited from the same suspenders-and-belt
concerning APPDATA and CSIDL_APPDATA for SL-10153.
|
|
In that case, also update $APPDATA for child processes.
|
|
The whole remaining difference between llifstream and std::ifstream is that
the former handles UTF-8 coded pathnames. Microsoft's implementation of the
latter does not.
|
|
|
|
Viewer (repository: axon)
|
|
|
|
|
|
|
|
Curiously, the value of $INSTDIR is correct before MULTIUSER_UNINIT, but is
made incorrect by MULTIUSER_UNINIT. Save and restore the correct value.
Saving $MultiUser.InstallMode in the registry (by setting relevant macros
examined by MultiUser.nsh) is susceptible to overwriting if the user installs
multiple viewers with the same channel name. Instead, write an InstallMode.txt
in the install directory, and read it back on uninstall. Of course, add it to
the files to be deleted on uninstall.
|
|
|
|
|
|
Back out misguided attempt to overwrite $PROGRAMFILES with $PROGRAMFILES64.
|
|
for 64-bit viewers.
It seems there's a longstanding bug in NSIS: it fails to use $PROGRAMFILES64
rather than $PROGRAMFILES when performing an all-users install of a 64-bit
program. Try to remedy that.
Also pick up a few NSIS suggestions from Ansariel Hiller.
|
