- Apr 24, 2017
-
-
Callum Prentice authored
pull in nickyd's changes to APR and LLCEFLib (Dullahan) for MAINT-6116 Console window appears breifly for Flash sites
-
- Apr 21, 2017
-
-
Callum Prentice authored
-
Callum Prentice authored
-
Callum Prentice authored
-
Callum Prentice authored
-
Nat Goodspeed authored
-
- Apr 19, 2017
-
-
Callum Prentice authored
-
Callum Prentice authored
Pull in improvements to LLProcess termination via a commit from Nat Linden here: https://bitbucket.org/rider_linden/doduo-viewer/commits/4f39500cb46e879dbb732e6547cc66f3ba39959e?at=default
-
Callum Prentice authored
Add back the missing pieces and updated code for the example plugin. It was useful during testing SLPlugin changes. Not shipped with release versions of viewer
-
Callum Prentice authored
-
Callum Prentice authored
Remove the scary 32bit exception handler that patches kernel32.dll since it was (a) scary, (b) didn't work on 64 bit and (c) likely the cause of a lot of anti-virus false positives
-
Callum Prentice authored
-
Oz Linden authored
-
Oz Linden authored
-
- Apr 06, 2017
-
-
Callum Prentice authored
-
Callum Prentice authored
Partial fix for MAINT-7236 Web content does not always respect UI Size preference (pull in new version of Dullahan with improved support)
-
Nat Goodspeed authored
-
- Apr 05, 2017
-
-
Callum Prentice authored
Fix for MAINT-7227 Drop down lists do not close after use in internal web browser. (Surprisingly large amount of changes and new version of Dullahan to support this fix)
-
- Apr 03, 2017
-
- Mar 30, 2017
-
-
Callum Prentice authored
fix for MAINT-6998 64bit viewer installs to Program Files (x86) by default. - this change also fixes MAINT-5365 Windows viewer uninstall icon is system default not SL logo
-
AndreyL ProductEngine authored
-
Nat Goodspeed authored
-
Nat Goodspeed authored
The previous LLSafeHandle<T> implementation declares a static data member of the template class but provides no (generic) definition, relying on particular specializations to provide the definition. The data member is a function pointer, which is called in one of the methods to produce a pointer to a "null" T instance: that is, a dummy instance to be dereferenced in case the wrapped T* is null. Xcode 8.3's version of clang is bothered by the call, in a generic method, through this (usually) uninitialized pointer. It happens that the only specializations of LLSafeHandle do both provide definitions. I don't know whether that's formally valid C++03 or not; but I agree with the compiler: I don't like it. Instead of declaring a public static function pointer which each specialization is required to define, add a protected static method to the template class. This protected static method simply returns a pointer to a function-static T instance. This is functionally similar to a static LLPointer<T> set on demand (as in the two specializations), including lazy instantiation. Unlike the previous implementation, this approach prohibits a given specialization from customizing the "null" instance function. Although there exist reasonable ways to support that (e.g. a related traits template), I decided not to complicate the LLSafeHandle implementation to make it more generally useful. I don't really approve of LLSafeHandle, and don't want to see it proliferate. It's not clear that unconditionally dereferencing LLSafeHandle<T> is in any way better than conditionally dereferencing LLPointer<T>. It doesn't even skip the runtime conditional test; it simply obscures it. (There exist hints in the code that at one time it might have immediately replaced any wrapped null pointer value with the pointer to the "null" instance, obviating the test at dereference time, but this is not the current functionality. Perhaps it was only ever wishful thinking.) Remove the corresponding functions and static LLPointers from the two classes that use LLSafeHandle.
-
andreykproductengine authored
-
Mnikolenko Productengine authored
MAINT-7245 Use Experience Box in LSL Editor will not show as checked if containing object is in another region
-
- Mar 29, 2017
-
-
AndreyL ProductEngine authored
-
Nat Goodspeed authored
When a 'family' code isn't recognized, for instance, report the family code. That should at least clue us in to look up and add an entry for the relevant family code.
-
- Mar 28, 2017
-
-
AndreyL ProductEngine authored
-
andreykproductengine authored
-
andreykproductengine authored
-
andreykproductengine authored
-
Mnikolenko Productengine authored
-
- Mar 27, 2017
-
-
Callum Prentice authored
Fix for MAINT-7131 Unable to start the x64 Viewer on Windows 8.1 x64. This appears to be because two of the MS DLLs we ship with the 64 bit viewer are 32bit. Manually replacing them with their 64 bit equivalents allowed the viewer to start on Windows 8.1. The change forces the cmake file which copies the DLLs to look in C:\windows\SysWOW64 for 32 bit versions and C:\windows\system32 for 64 bit versions. (yes really).
-
Callum Prentice authored
Additional work on : Fix for MAINT-7054 Viewer Crashed when I used Japanese IM. (Drake and Appurist convinced me my initial solution was non-optimal)
-
Callum Prentice authored
-
Mnikolenko Productengine authored
-
- Mar 24, 2017
-
-
andreykproductengine authored
-
- Mar 23, 2017
-
-
Mnikolenko Productengine authored
-