When to use PreCanInvoke vs. PreInvoke?

Siebel server scripting provides more than one option to do the same thing.

Developers can use different methods available in the object to suit their needs. Often, any initial choice made in hurry, will become the standard for all future scripts.

The option of choosing PreInvoke as against PreCanInvoke in the applet server script is one of them. It does not matter whether it is eScript or Siebel VB.

The end objective of using these two methods may be the same: to conditionally enable/disable button on the UI.

PreCanInvoke checks the condition at the time of applet load, and disables the button altogether. PreInvoke Does not have any effect on disabling the button, but can check the condition and proceed with the further steps only the condition is satisfied.

PreCanInvoke has its advantages -

• Provide visual cues to the user to not click on a button that will simply not work due to conditions not being satisfied
• Avoid error dialogues to be popped up everywhere in the application ( it is considered annoying from a user experience perspective)

There are problems however -

• Users do not know why your button is not enabled. If there are multiple, complex criteria that enable a button, it will take a genius to find out what exactly has gone wrong
• This is especially problematic when the application is exposed to external users who may be quite new
• Since all the conditions are being checked at the time of applet load, it may decrease the performance of the application overall

PreInvoke solves these problems somewhat. You check the conditions to enable the functionality behind the button only when the user clicks on the button. You show appropriate error/warning messages to the user if the conditions are not satisfied.

This works well especially with the application is being used by users external to the organisation. The problems are -

• Too many error dialogue boxes
• Users have two click on each pertinent to see whether all the conditions have been satisfied

Until Open UI works out some magic (OOB!) to show unsatisfied criteria and thereby help the user on when a button is “click ready”, establish these basic design principles-

• Use PreCanInvoke When the conditions are simple and users are able to understand why a button is disabled intuitively
• If the conditions are technically complex and need explicit queries to be fired off, transfer the logic to PreInvoke
• On button click, collect all possible unsatisfied criteria. Show an unified error message to the user
• Evaluate use of a task focused UI, rather than enabling 10 buttons on the same applet and expecting the user to figure that out