As Sage 200 developers we’re all very aware the need to generate a simple “stub” script to hook into the instantiation of a Sage 200 amendable form in order to control its customisation, these scripts usually look something like:
Imports Tilted.Sage200.Magento.Customisations.Stock
Module addInModule
Public Sub main
Dim o as new ItemDetails(Form)
End Sub
End Module
Some of us may have also attempted to use the Initiator / Messaging pattern and subscribed to the SubscribeBeginLoad message and probably all faltered at the same point due to the first “break†line of code in here:
protected void OnBeginLoad()
{
if (this.IsApplicationConnected && !this._bFormLoaded)
{
if ((BeginLoadDelegatesList != null) && (BeginLoadDelegatesList.Count > 0))
{
for (System.Type type = base.GetType(); type != null; type = type.BaseType)
{
EventHandler handler = (EventHandler) BeginLoadDelegatesList[type];
if (handler != null)
{
handler(this, EventArgs.Empty);
break;
}
if (type.Equals(typeof(BaseForm)))
{
break;
}
}
}
this.ApplyCustomisation();
}
this._bFormLoaded = true;
}
I’ll not go into reasons why, if you’ve not tried this perhaps give it a try and find the underlying problem for yourselves.
The only supported way of doing this does actually involve scripting – but only the one, the not commonly used common.vbs, this script is executed for every Sage 200 form that follows the scripting pattern and you’re probably well aware of its presence.
What we don’t do however is follow the obvious approach of grabbing the Sage.Common.Amendability.AmendableForm object, testing its type and executing the appropriate method to customise it, we’re going to create something considerably more useful using our own implementation of a form instantiation subscription model.
Pretty much all Sage 200 developers have a “base†addon which contains functionality shared across multiple addons, for this we’re going to need ours to include a common.vbs script containing a single FormController.Invoke statement:
Imports Tilted.Sage200
Module addInModule
Public Sub main
Tilted.Sage200.FormController.Invoke(Form)
End Sub
End Module
The idea is to have a FormController class in your base addon which deals with all the form hooks required by all the addons that use the base (including itself), the effect of this is that any addon that utilises the functionality provided by the base is indeed (as the title suggests) scriptless.
Instead of using scripts to inform Sage that we wish to customise a form, we use subscription code in the initiator to inform the base addon that you wish to customise a form, something similar to below:
FormController.Subscribe(typeof(Sage.MMS.SystemManager.SystemSettingsForm), (EventHandler)System_SystemSettingsForm);
When the FormController gets notification of the Sage.MMS.SystemManager.SystemSettingForm being opened it will invoke the method defined as System_SystemSettingsForm below:
void System_SystemSettingsForm(object sender, EventArgs e)
{
new Customisations.SystemManager.SystemSettings(sender as Sage.Common.Amendability.AmendableForm);
}
This method then instantiates a new SystemSettings class passing in the amendable form object, this class can then operate as though it was created from a standard vbscript.
Taking it a small step further you could also include license testing in the subscription:
FormController.Subscribe(typeof(Sage.MMS.SalesLedger.SalesInvoiceForm), (EventHandler)SalesLedger_SalesInvoiceForm, LicenseTypeEnum.Utilities);
So that the subscription only gets invoked if the site is licensed to use the specific piece of software – in the above it’s our set of Sage 200 utilities.
There’s a lot that needs to be considered when building the FormController which may be covered in a future article, for now though we’ll leave that as an exercise for yourselves.
As with any article posted here, if you would like any more information just get in touch.
Back to News