Right. I've attached a sample plugin. A sql script is included on the plugin as a "document" - save and run this sql script in SQL Management Studio to create the table used by the plugin.
The basic structure of the code is this:
1. Add some events when Setup is called.
2. When the general ledger maintenance form loads, setup and add our controls. Also set up some stuff in the business logic.
3. Every time a general ledger account is read, read our custom stuff from the database and update the display on the general ledger maintenance form.
4. Every time a general ledger account is saved, save our custom value to the database.
5. Every time a new general ledger account is created, reset our custom stuff to a default value and update the display on the general ledger maintenance form.
It's written in c#, and I've not done much c# work, so be gentle
. I'd like to have put in some more defensive code, and re-factor it a bit more, but it would take me too long to figure out in c# at the moment. (ie. Why can't I do collection.contains() ??). I'd also consider changing the design completely such that it was split into 2 plugins - one that was business logic-centric and another that was form-centic. The current design does not cater for a 3rd party using the general ledger business logic without a form - they would not be able to see or use our custom "DefaultBASCode" field. I figure for our purposes here this is OK, however.
What is also noteworthy is the use of the generic object collection in the business logic object. I leveraged this so that I had access to what I needed no matter whether I was in a business logic event handler or a form event handler. Likewise, see the use of the business logic "client" property - this allows us to access the form when only the business logic is available.
Anyway, you should find it helpful, even if you end up converting it back to VB. Give me a yell if you have questions, or even some c# tips for me!