CONTROL CALCULATION allows an EASAP to be in an incorrect or indeterminate state so should be used with care and only to remedy existing performance issues. There is no more general reason to add this ACTION to an EASAP. It significantly disrupts the automatic behaviour of an EASAP and may have unintended consequences.
|Action:||Choose from DISABLE, ENABLE, REFRESH to act upon Mode:|
|Mode:||Select the functionality to modify (EASAP Calculation,Excel Calculation, Excel Connection)|
|Do if:||Logical expression, if FALSE do not do ACTION. default→TRUE|
|Spreadsheet:||Apply the change to a specific spreadsheet|
|Refresh View:||If FALSE, GUI will not update after an ENABLE or REFRESH. Eventually should be set to TRUE to make new values visible. default→TRUE, FALSE|
CONTROL CALCULATION allows three different levels of control within an EASAP, Authors may retain control or in some cases Users themselves might be given control to 'commit' data when they are finished with data entry.
For each Mode: the User or Author will first set Action: to DISABLE. Later, after data has been entered, Action: will be set to ENABLE or REFRESH can be used to combine an ENABLE-then-DISABLE in one single ACTION (ie. with REFRESH, Action: will return to DISABLE'd status).
The least disruptive Action: is Excel Calculation which if DISABLE'd will suspend Excel's updating of dependent cells until Excel Calculation is ENABLE'd or REFRESH'd again. This should raise the responsiveness of Excel REFERENCE's and NAMED RANGE's.
If the above does not create an adequate performance gain Excel Connection may be DISABLE'd. A User may enter many data values and then update the corresponding Excel fields at a later time when data will be exchanged with the Excel Server by setting Action: to ENABLE or REFRESH. This Mode: is useful for an EASAP with many simultaneous users.
The most drastic EASAP state modification is DISABLE'ing EASAP Calculation. This Action: suspends any propagation of state changes for all objects in an EASAP (ie. Do if:, Enable if:, data validation are all affected).
The primary goal of this mode is to allow a User to enter data into many fields without having to wait between adjacent data entry fields in an EASAP with complex processing. Processing is suspended until some later point in time when a REFRESH or ENABLE commits the data into the EASAP and processing to update 'dependent' object's states commences.
Dependencies between GUI objects may or may not involve processing. In the later case GUI objects will update immediately (for example an updated INPUTBOX value displayed in a LABEL→ the LABEL will update with a new value in INPUTBOX) even though EASAP Calculation is DISABLE'd.
Changes to the Action: parameter may be initiated by the Author via EVENT's within the EASAP or conversely the User may initiate the changes in status using BUTTON's, a MENU ACTION, or TAB SELECTED within the EASAP.
In general it is good design to have an EASAP's input and output data fields on different tabs to limit the possibility that old or stale values will persist in the visible GUI causing confusion while calculation is suspended.