Merge "Type registry helper: Toolkit change to correct Programming Guide for Custom...
[platform/core/uifw/dali-toolkit.git] / docs / content / programming-guide / properties.h
index 2d8d7e6..1033b5f 100644 (file)
@@ -79,7 +79,7 @@ DALI_PROPERTY_TABLE_END( DEFAULT_DERIVED_ACTOR_PROPERTY_START_INDEX )
 - The parameter to DALI_PROPERTY_TABLE_END should match the start index of the property enumeration.
 
 <br>
-<h2 class="pg">How to implement a property within Dali-toolkit:</h2>
+<h2 class="pg">How to implement a property within Dali-toolkit controls and application-side custom controls:</h2>
 
 Macros are used to define properties for the following reasons:
 
@@ -153,6 +153,10 @@ Note that the “PropertyRange” contents “PROPERTY_START_INDEX” & "ANIMATA
 
 Source file: <b>image-view-impl.cpp</b>, within an unnamed namespace:
 
+@code
+#include <dali/public-api/object/type-registry-helper.h>
+@endcode
+
 @clip{"image-view-impl.cpp",DALI_TYPE_REGISTRATION_BEGIN,DALI_TYPE_REGISTRATION_END}
 
 <b>Notes:</b>
@@ -161,6 +165,9 @@ Source file: <b>image-view-impl.cpp</b>, within an unnamed namespace:
 - Properties should be in the same order as in the enum.
 - Signals and actions are registered likewise in that order.
 - Properties type-registered using these macros will have their order checked at compile time. If you get an indexing compile error, check the order matches the enum order.
+    The error will look like this: " error: invalid application of 'sizeof' to incomplete type 'Dali::CompileTimeAssertBool<false>' "
+- If using the Pimpl design pattern when creating a custom control from within an application, the Handle (public) and Object (internal) classes should have the same name. They can be separated by different namespaces.
+    This requirement is actually due to how the type-registry in DALi looks up properties.
 
 <br>
 <hr>