Form
Overridden rate is calculated as the ratio of the number of forms, where a method is overridden, to the total number of forms.
Not surprisingly,
init method is almost always overridden. run, close and closeOk methods are often overridden. All other methods are rarely overridden.The following methods are never overridden in standard application:
addHistory
blockPersonalization
closedCancel
controlMethodOverloadObject
copy
getActiveWorkflowConfiguration
getActiveWorkflowTrackingStatus
getActiveWorkflowWorkItem
initWorkflowControls
loadUserSetting
reload
send
setApply
skipSaveUserSetting
updateWorkflowControlsDatasource
Overridden rate is calculated as the ratio of the number of datasources, where a method is overridden, to the total number of datasources.
init, active, executeQuery, write, validateWrite, initValue, delete, linkActive, create.All other methods are rarely overridden.
The following methods are never overridden in standard application:
defaultMark
findValue
markAllLoadedRecords
refreshExConclusion
This standard application statistics reflects what is usually overridden by a developer on a regular project:
-
init, run, close methods on a form-
init, active, executeQuery, write methods on a form datasource.
Hi Oleg, I think this is interesting analysis, especially for someone wanting to learn more about form customisations. In my view it demonstrates which specific methods are the most important to understand to bring the biggest learning benefit. If you wrote some X++ to produce these stats then that would also be interesting to share. Then perhaps it would be possible to adapt the code in order to identify forms that make use of specific methods. I think this would help learning.
ReplyDeleteHi Mike, thank you very much for the comment. You absolutely correctly described the purpose of this post. I did not save x++ code, but it was quite primitive. I will try to restore and improve it one day.
Delete