appdata example// When creating a page container: container->appdata=f->create_input_field("", config); // ... pl->on_opened([] (ONLY IN_THREAD, 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; f->request_focus(); });
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 widget.
The on_opened
callback only needs to fetch the opened page's widget.
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 widgets”,
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 widgets also get removed.
Only storing a reference to a parent widget, in its child's
appdata,
creates a circular reference because of the internal reference from
the container to each child widgets.