Actually, the maintenance form toolstrip is designed to talk to the Primary Business object of the form rather than the first in the collection.  Many times the primary BO happens to be the first item on the collection though, but ultimately it is the primary BO.  You have two options.  One, you may consider creating a user control that has a maintenance form toolstrip on it and then transate the BOs through the BOTranslations property.  Second option is to create your own toolstrip, which really would not be a difficult task since there is not that much functionality that needs to be added.  You could also expose a property on your toolstrip that accepts a BO as a property and the toolstrip then manages that BO.

Thanks Greg;



But I really need to deal with each BO independently, and I don't want to roll my own toolstrip, since I'm in the middle of writing an application and not creating and debugging controls. I think if SF team make this property public, then we can override the BO with the secondary one on the form.



I'm waiting for SF team to respond to this post. My other alternative to create another form, but that defeat the purpose of having everything for the user in one form.



Trent, can we easily solve this problem? I'm going to have many forms that are going to be dependent of Stores and then within customer file, I need multiple toolstrip to create multiple shipping address, credit cards, notes and etc.



Thanks!

..ßen

The maintenanceformtoolstrip is designed to connect to the first BO in the collection of BOs associated with the form. You can have as many as you want on a form, but they will all talk to the same BO (actually, god only knows what would happen if you had multiple on the same form).



With a bit of work you could just roll your own. The browse dialog functionality is the only part I'm not familiar with. Just make a toolstrip with edit, add, save, undo and remove buttons as well as the move first, previous, next and move last. Add a BusinessObject public property of type BusinessLayer. I'd add the ResetBusinessObject and ShouldSerializeBusinessObject properties to, to support the designer. Wire up the buttons using the BO methods. Finally, react to the EditStateChanged and Navigated events to enable/disable the buttons as needed.



Then you can have as many as you like on a form.



However, before you do that, if the BOs are related (a parent and many children), I'd try just settings in the "StrataFrame: Form Include Settings". By setting the IncludeInFormAdd, IncludeInFormEdit, etc. properties to True, the maintenanceformtoolstrip will work with any BO with these properties to true. The first BO in the collection (the main BO), will have all of these set to true. Others by default with have only IncludeInFormSave set to true. If you setup the parent relationship for the BOs, then set the parent BO on the instances, set the appropriate properties to have child records filtered and have set the IncludeInForm[n] properties, then all editing/navigation will be in synch and parent/child relationship managed.



I have done the first (manage each BO separately), but I'm going to be investigating the other method. It seems easier, the user experience is nicer (they don't care about parent/child stuff...they just want to edit/add stuff), but I don't know the limitations/gotchas yet.



Good luck.

I have a form that creates the info for a "Store". As part of this form there is a MaintenanceToolStrip there.



Once the user creates the store and the store is selected, on the right side, I have designate an area that the user can cab create multiple employees for that store. For that, I placed a second MaintenanceTooStrip to connect to my EmployeeBO, so the user can add/edit/delete employees while they are in store form.



I can't find a property to connect the MaintenanceStripTool to a BO. This is a common thing that you can navigate between master/detail records within the same form.



Thanks!

..ßen