Age | Commit message (Collapse) | Author |
|
|
|
|
|
- When accepting an avaline call, add a caller to the recent list as AvalineListItem
- When adding item to the LLRecentPeople, check whether item with the same phone number exists and delete it if exists. This is need to avoid duplication in the Recent list of the panel People.
|
|
|
|
As people will have to rebuild half the tree anyway, because these
headers changed, we might as well prettify them a bit.
|
|
Not related, just a while-I'm-at-it thing.
|
|
‘getNextFileInDir’
Before OPEN-29, when lldir_win32.h would have been included when
building for Linux, GCC would error out with
indra/llvfs/lldir_win32.h:50: error: extra qualification ‘LLDir_Win32::’ on member ‘getNextFileInDir’
which, although unintended, probably was a Good Thing (TM), as this
would have aborted the build, so that the wrong include would be
noticed. Now that we explicitly error out with a (hopefully) useful
error message, this isn't needed anymore.
|
|
different platform
As far as I know, there is no good reason to include e.g.
indra/llvfs/lldir_win32.h while not building for a windows target, so be
better prevent this to avoid hard to find errors.
|
|
the left side when clicked.
|
|
|
|
systems
|
|
|
|
Test also passes overlong arrays and maps with extraneous keys; in all cases
we expect the same set of values to be passed to the registered functions.
|
|
|
|
|
|
|
|
Members list.
|
|
|
|
|
|
|
|
LLSurface::getWaterHeight
|
|
been used
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
current working
Reviewed by Richard - http://codereview.lindenlab.com/6011001/
|
|
Landmark panel. Not in scope of this jira.
|
|
to the parcel API
|
|
|
|
We'd introduced FunctionsTriple to associate a pair of registered function
names with the Vars* on which those functions should operate. But with more
different tests coming up, it became clear that restating the Vars* every time
a given function name appeared in any such context was redundant.
Instead, extended addf() to accept and store the relevant Vars* for each
registered function, be it the global Vars for the free functions and static
methods or the stack Vars for the non-static methods.
Added varsfor() function to retrieve and validate the Vars* for a given
function name.
Eliminated array_funcs() function, restating aggregates of names to test as
LLSD collections. Where before these were coerced into a separate LLSD map
with ["a"] and ["b"] keys, that map can now be part of the original structure.
|
|
|
|
Settings windows
|
|
An array-registered function has no param names, so you can only pass an
array: a map would be meaningless. Initial implementation of map-registered
functions assumed that since you CAN pass a map, you MUST pass a map. But in
fact it's meaningful to pass an array as well -- for whatever reason -- and
easy to implement, so there you are. Tests to follow.
|
|
|
|
LLSDParam<const char*> is coded to pass NULL for an isUndefined() LLSD value,
so event-based caller can choose whether to pass NULL, "" or whatever string
value to such a parameter. Ensure this behavior.
|
|
One operation we often use is to take an LLSD array of param names, a
corresponding LLSD array of values, and create from them a name=value LLSD
map. Instead of doing that "by hand" every time, use a function.
|
|
Streamline a bit more redundancy from the code in that test.
|
|
Following the C++ convention of having two distinct somethigna, somethingb
names, initially we introduced paramsa, paramsb LLSD arrays, following that
convention all the way down the line. This led to two distinct loops every
time we wanted to walk both arrays, since we didn't want to assume that they
were both the same size. But leveraging the fact that distinct LLSD arrays
stored in the same LLSD container can in fact be of different lengths,
refactored all the pairs of vars into top-level LLSD maps keyed by ["a"] and
["b"]. That lets us perform nested loops rather than duplicating the logic,
making test code much less messy.
|
|
Naively storing a const char* param in a const char* data member ignores the
fact that once the caller's done, the string data referenced by that pointer
will probably be freed. Store the referenced string in a std::string instead.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A certain popular-but-dumb compiler seems to think that initializing a
std::vector from a pair of iterators requires assignment. A struct containing
a reference cannot be assigned. Pointers get us past this issue.
|