DannyC wrote:Can you explain the usage of GenericObjectCollection a bit?
Some of our base classes (like the Maintenance forms and the maintenance Business Logic) have a property called GenericObjectCollection. It's not used by Jiwa, it's purpose for plugins to store "stuff" in there for an instance of the form or business logic. The collection is just a standard Jiwa collection of GenericObjectItem - which is just simple class with just two important properties - RecID and Object.
You shove something into the instance of an object by deciding on a unique identifier and a value - in this example we are going to create and add to the GenericObjectCollection of the debtor instance a GenericObjectItem with a RecID (the unique identifier) of "ParentDebtorID" and the value we're going to give it is the debtors parent debtor ID. It does not have to be a string, you can store anything in there.
- Code: Select all
debtor.GenericObjectCollection.SetOrAdd("ParentDebtorID", debtor.ParentDebtor.DebtorID);
And later on, when we want to retrieve the value of the thing we stored in the "ParentDebtorID" item, we can retrieve that with:
- Code: Select all
string parentDebtorID = debtor.GenericObjectCollection.GetValue<string>("ParentDebtorID");
The GetValue method has a Generic parameter indicating the Type you want is to convert the Object to before returning it.
The reason why we use this is because with Plugins you cannot just declare a private variable of the class and store the value in there - because the classes (FormPlugin, BusinessLogicPlugin and so on) in the plugin are not created every time a form or business logic is loaded - we create those at application startup and invoke the Setup Method every time a form or business logic is loaded - so loading two Debtor forms in your example here would mean if we put the ParentDebtorID into a private variable of the class, it would be set by the first form load, then when a 2nd instance of the debtor form is loaded (the first one still open too), it overwrites that value and so when you switch back to the first debtor it would behave as though it had the parent debtor id of the 2nd form's debtor - not what you want.
So, the GenericObjectCollection is just a tool you can use to store things which are not shared across instances of objects.
DannyC wrote:I was also stumped on this line
- Code: Select all
branchDebtor.BranchDebtor.ReadRecord(debtor.DebtorID)
A debtor has a collection of BranchDebtors in the BranchDebtors property. To add a debtor as a branch of another debtor you need to add to the BranchDebtors collection of the debtor to act as the parent. This collection wants items in itself to be of type JiwaFinancials.Jiwa.JiwaDebtors.BranchDebtor - so you create one of those - but before you add it to the BranchDebtors collection, there is a property "BranchDebtor" which needs to be "read" - this is our generic debtor Entity - it has a method ReadRecord which accepts a DebtorID to read the debtor information.
Looking at the types of the properties will make things much clearer - it's easy to become confused when we have things like Debtor entity and Debtor Business logic classes and the Debtor Business Logic (JiwaDebtors.Debtor) has a property named BranchDebtors which is a collection of JiwaDebtors.BranchDebtor which contains a property that is called BranchDebtor but it's type is JiwaFinancials.Jiwa.JiwaApplication.Entities.Debtor.Debtor.
Like Scott mentioned, and others have also mentioned this in the past - use a disassembly tool to generate the source code from our Assemblies and then everything should become much easier to grok by looking at how we do things. In this case, you'd want the JiwaDebtorsUI.dll disassembled to see how our Debtor Maintenance form adds a branch debtor using the Debtor Business Logic.