Prima

 view release on metacpan or  search on metacpan

pod/Prima/Object.pod  view on Meta::CPAN

allow OBJECT to be undef, while some do not. All widget objects can not exist
without a valid owner; Prima::Application on the contrary can only exist with
owner set to undef. Prima::Image objects are indifferent to the value of the
owner property.

Changing owner dynamically is allowed, but it is a main source of
implementation bugs, since the whole hierarchy tree is needed to be recreated.
Although this effect is not visible in perl, the results are deeply
system-dependent, and the code that changes owner property should be thoroughly
tested.

Changes to C<owner> result in up to three notifications: C<ChangeOwner>, which
is called to the object itself, C<ChildLeave>, which notifies the previous
owner that the object is about to leave, and C<ChildEnter>, telling the new
owner about the new child.

=back

=head2 Prima::Component events

=over 4

=item ChangeOwner OLD_OWNER

Called at runtime when the object changes its owner.

=item ChildEnter CHILD

Triggered when a child object is attached, either as
a new instance or as a result of runtime owner change.

=item ChildLeave CHILD

Triggered when a child object is detached, either because
it is getting destroyed or as a result of runtime owner change.

=item Create

The first event an event sees. Called automatically after init() is finished.
Is never called directly.

=item Destroy

The last event an event sees. Called automatically before done() is started.
Is never called directly.

=item PostMessage SCALAR1, SCALAR2

Called after post_message() call is issued, not inside post_message() but at
the next idle event loop.  SCALAR1 and SCALAR2 are the data passed to
post_message().

=item SysHandle

Sometimes Prima needs to implicitly re-create the system handle of a component.
The re-creation is not seen on the toolkit level, except for some repaints when
widgets on screen are affected, but under the hood, when it happens, Prima
creates a whole new system resource. This happens when the underlying system
either doesn't have API to change a certain property during the runtime, or
when such a re-creation happens on one of component's parent, leading to a
downward cascade of children re-creation. Also, it may happen when the user
changes some system settings resolution, so that some resources have to be changed
accordingly.

This event will be only needed when the system handle (that can be acquired by
C<get_handle> ) is used further, or in case when Prima doesn't restore some
properties bound to the system handle.

=back

=head1 AUTHOR

Dmitry Karasik, E<lt>dmitry@karasik.eu.orgE<gt>.

=head1 SEE ALSO

L<Prima>, L<Prima::internals>, L<Prima::EventHook>.



( run in 0.680 second using v1.01-cache-2.11-cpan-39bf76dae61 )