There are scenarios when the use of is either redundant or not recommended:
Do not manage Field States with behaviors
If you want to set a field state (normal, hidden, read-only and disabled) based on a workflow or role, do not use the Set State . Controlling field states in this manner will require extensive behavior creation on your part. To control based on actions occurring within the app, behaviors are more appropriate.
|
Do not manage Object Properties with behaviors
Do not use behaviors to manage that can be controlled on the .
Many app objects offer properties that manage data input, making additional behaviors unnecessary. For example, a Text Input object allows you to specify the type of data input (e-mail, alpha, numeric). Additionally, a numeric input object can have minimum and maximum values configured on the Properties panel.
However, in certain circumstances it may be necessary to modify the default properties of an object such as position, size or colors using behaviors. Use the Set Property command to manage this.
|
Do not overuse Branch Commands
Special behavior commands can efficiently manage in a single command what would otherwise require a sequence of simple commands.
For example, the Check Mandatory command allows you to manage required field checking with just the one command rather than using a sequence of Branch ('if') commands.
|
Do not attempt to manage Workflow with Behaviors
In most cases (with the exception being the implementation of notifications), avoid using behaviors to manage . Although behavior commands are used on workflow paths, most workflow logic should be handled through the .
For more information, see the Adding Workflow topics.
|
Return to Adding Behaviors, Designing an App
See: Behavior Processing Messages