Struct binaryninja::custombinaryview::CustomViewBuilder

pub struct CustomViewBuilder<'a, T: CustomBinaryViewType + ?Sized> { /* private fields */ }

Represents a request from the core to instantiate a custom BinaryView

Implementations

impl<'a, T: CustomBinaryViewType> CustomViewBuilder<'a, T>

pub fn create<V>( self, parent: &BinaryView, view_args: V::Args ) -> Result<CustomView<'a>>

where V: CustomBinaryView,

Begins creating a custom BinaryView.

This function may only be called from the create_custom_view function of a CustomBinaryViewType.

parent specifies the view that the core will treat as the parent view, that Segments created against the created view will be backed by parent. It will usually be (but is not required to be) the data argument of the create_custom_view callback.

constructor will not be called until well after the value returned by this function has been returned by create_custom_view callback to the core, and may not ever be called if the value returned by this function is dropped or leaked.

Errors

This function will fail if the FileMetadata object associated with the expected parent (i.e., the data argument passed to the create_custom_view function) already has an associated BinaryView of the same CustomBinaryViewType. Multiple BinaryView objects of the same BinaryViewType belonging to the same FileMetadata object is prohibited and can cause strange, delayed segmentation faults.

Safety

constructor should avoid doing anything with the object it returns, especially anything that would cause the core to invoke any of the BinaryViewBase methods. The core isn’t going to consider the object fully initialized until after that callback has run.

The BinaryView argument passed to the constructor function is the object that is expected to be returned by the AsRef<BinaryView> implementation required by the BinaryViewBase trait. TODO FIXME welp this is broke going to need 2 init callbacks

pub fn wrap_existing( self, wrapped_view: Ref<BinaryView> ) -> Result<CustomView<'a>>