An appdata example

// When creating a page container:

container->appdata=f->create_input_field("", config);

// ...

      const x::w::book_status_info_t &info)
             size_t n=info.opened;

             auto page=info.lock.layout_manager->get_page(n);
             x::w::input_field f=page->appdata;

booklayoutmanager.C gives another example of using appdata. booklayoutmanager.C takes the first x::w::input_field on each page, and puts it into the appdata of each page's x::w::container element.

The on_opened callback only needs to fetch the opened page's element. get_page() returns the x::w::element base class references. The callback grabs the x::w::input_field from the appdata, and put keyboard input focus into the input field every time one of the pages gets opened.

As explained in the section called “Attaching application data to display elements”, parent containers hold internal references to all objects in the container, and in this manner booklayoutmanager.C also does the same itself, storing a reference to an x::w::input_field in its parent container that comprises a page in the book.


The requirements explained in the section called “Special rules for captured references in callbacks” do not apply here. booklayoutmanager.C's on_opened callback does not capture any references, and only uses its parameters to retrieve the newly-opened page.

The reference stored in each container's appdata is not associated with any callback. It's just an ordinary reference pointer for an object. The reference pointer to a child object gets stored in each parent, like LibCXXW normally does; and once the parent container gets removed, its references to its child display elements also get removed.

Only storing a reference to a parent display element, in its child's appdata, creates a circular reference because of the internal reference from the container to each child display elements.