[Bf-committers] Getting the associated Blender object name from a uiBut object
The Simple Carnival
jeff at simplecarnival.com
Tue Aug 8 04:24:10 CEST 2017
That worked! Thank you, Lukas.
On 8/7/2017 9:50 PM, Lukas Stockner wrote:
> The PointerRNA contains two data pointers, in your case, you'll probably want to use ptr.id.data - while it's a void*, it will point to some ID datablock, so ((ID*)(ptr.id.data))->name should contain "OB<your object name>".
> Am 08.08.2017 um 03:27 schrieb The Simple Carnival:
>> Actually, I take that back. It's pretty messy to handle that from the
>> Restrict View section because it would mean overriding the ability to
>> turn on/off the view/select/render icons. Plus, out of the available
>> modifier keys (shift, alt, oskey -- ctrl is already taken), only shift
>> appears to work on Windows. I need the ability to insert, replace, and
>> delete keyframes, and shift can't handle all those cases. So I'm back to
>> handling this as right-click "Insert/Replace/Delete Recursive Keyframes"
>> menu option.
>> All I need is the ability to get the name of the associated Blender
>> object name from a uiBut object; from there, I know how to handle
>> everything else. I'm thinking that the key is this, in particular ptr in
>> the second line:
>> but = UI_context_active_but_get(C);
>> UI_context_active_but_prop_get(C, &ptr, &prop, &index);
>> (ptr is a PointerRNA, prop is a PropertyRNA.)
>> I *think* I can somehow take ptr and get the actual blender object it's
>> pointing to. However, I'm having difficulty figuring out how to do that.
>> Any ideas?
>> On 8/6/2017 9:39 PM, The Simple Carnival wrote:
>>> Hi Matt --
>>> Thanks for the tip. I was able to get a proof-of-concept working going
>>> off of that code instead of dealing with the uiBut objects. I'll dig
>>> more into this, but I think I can make it work.
>>> On 8/6/2017 5:15 PM, Matthew Keller wrote:
>>>> Hi Jeff,
>>>> Not sure if you've seen this, but there is a way to perform the
>>>> 'Restrict View' action in the ui recursively by pressing Ctrl while
>>>> clicking. This is the function that enables that behavior as far as I
>>>> can tell:
>>>> They seem to be using the currently selected object and then
>>>> iterating through all the objects and checking every time if the
>>>> object is a child of the currently selected object.
>>>> Could you follow that approach by setting the keyframe on the
>>>> underlying object as opposed to setting the keyframe on the button?
>>>> (there's even logic in there to actually set the keyframe, although
>>>> I'm not quite sure under what circumstances that functionality is
>> Bf-committers mailing list
>> Bf-committers at blender.org
More information about the Bf-committers