Am Wednesday 11 January 2012 10:07:55 schrieb Henri Beauchamp:
> Oops...
>
> There was a bug in the patch I sent for v1 viewers (I forgot to replace
> mFolderAdded(FALSE) with mFolderAdded(folder_added) in the constructor
> of LLInventoryCopyAndWearObserver).
>
> Attached to this email is the fixed patch.
>
> Henri.
Thank you for porting, Henri!
And yes, it would be very good to have somwhere to test in the betagrid, there
are a couple of things I think it would good to have an eye on:
* in LLFloaterOpenObject::moveToInventory it looks to me that at least a
LLCategoryCreate object gets leaked if a null category_id is returned,
however all the
// If we get a null category ID, we are using a capability in
// createNewCategory and we will handle the following in the
// callbackCreateInventoryCategory routine.
if (category_id.notNull())
seems to contradict whats actally happening in
LLInventoryModel::createNewCategory: null id returned on 2 possible failures,
non-null in all other cases including success.
* LLInventoryModel::createNewCategory returns a non-null id, even though
requesting the cap failed if :
- one or both of callback or user_data == NULL (ok, that is both rather
unlikely)
- the cap url is empty (e.g. the capability response didn't arrive (yet)).
About that Im not so sure that it can not happen: buy new avatar, tp to
busy sandbox on a busy weekend and have a bad network route anyway, rezz -
open - copy and wear directly after teleport ... not sure yet how to simulate
that in the betagrid, but I want to see what happens before it does to users.
Armin
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
