Things to be careful with when using Custom Properties

Things to be careful with when using Custom Properties

You should always test your custom properties signed on as an end-user and using the UF_EXEC (or equivalent) entry point. Testing while signed on as designer (UF_DESGN or equivalent) or as an administrator (UF_ADMIN or equivalent) is not advisable.     

If you do wish to test your custom properties while using the Framework as a designer or administrator then you should always save and restart the Framework after making any changes to custom property definitions and before running applications that access them.   

You should always specify a default value for any property. There are several reasons for doing this:

• If the property cannot be changed by the administrator then this is of course essential.

• If the administrator does not set or change the property for a specific user then the value is not stored with the user. The current default value is always used.  

• If the property can be changed by the administrator then a good default will save the administrator time and reduce your support costs.     

Spending three minutes on simple custom property help text now may save you a day of support time later.

If you change the definition of an existing custom property and/or remove values from a list associated with it and then (re)deploy your Framework definition you need to carefully consider the ramifications, especially if many users already have their own unique values and lists for the property saved.   

While there is no specific limit on how many custom properties you can define with in a Framework, having more than 100 would mean that your Framework might start to encounter some usability issues.

When using Custom User properties in WAMs, do not set or retrieve custom user properties in the uHandleEvent routine.  Allow the Framework to initialize the WAM first. Set or retrieve custom properties in the uExecute or other routines.