Walter,

This IS one big message! <g>

>This leads to the big question - how would you go about implementing an MVC framework where, for example, there are two or more forms sharing the same business objects (or otherwise copy of data). Failing the perfect implementation of this, how might one form communicate to another that its copy of data is out of date and needs to be refreshed? (In VFP where there was the same issue with two forms having private datasessions, we used to implement a kind of "Broadcast Data-Needs-Refreshing message" which told a form to requery, but having the forms work off the same model would be better).

At times its desirable for forms to have their own copy of a business object, but to get thesort of functionality you mentioned above, you can create business object reference static properties on the application object like this (note the use of lazy instantiation):

class AppDesktop : mmAppDesktop
{
	public static Orders oOrders
	{
		get 
		{
			if (_oOrders == null)
			{
				_oOrders = new Orders();
			}
			return _oOrders; 
		}
		set { _oOrders = value; }
	}
	private static Orders _oOrders;

You can then register these objects on your forms like this:

this.RegisterBizObj(AppDesktop.oOrders);

>It sounds like next version of MM.NET should cover my current gripe about making user controls with their own business logic (see messages in this forum earlier this week. Must be my proximity to Australia that I wanted this too <g>)

Yessir!

>The BindingSource properties of Windows form controls refer to Entity names, so what happens if you need to have two business objects managing the same entity (for example, two lists, one "Links to" and the other "Links from", both lists of Link entities, with different current rows)

In this case, rather than using the built-in business object / UI registration, you can manually register controls with a specific business object like this:

BusinessObject.StateChange += new mmBusinessStateChangeDelegate(MyControl.StateChangeHandler);

>1. Entities involving a subcategory relation
>
>eg Party - o||-- Customer and Party --o||-- Supplier. I haven't tried this out on the Business Layer generator yet but I suspect it would only cope with a view. At the business object level, I'd want Customer to inherit from Party, CustomerEntity to inherit from PartyEntity etc.

I'm not sure I understand the scenario, but you can definitely create entities and business objects that are subclasses of other entities and business objects. In the second page of the Business Layer Generator, you can specify a different base class for both the business object and the entity object.

>2. Lookup values in related tables in a data grid view or on a form. Basically, like readonly comboboxes without displaying the "arrow down" button. As far as I can tell, I've only seen this done (in .NET) by binding the grid to a view or other manufactured data table (It's an awful lot easier just to use a readonly combobox!). (Ironically, in VFP that's usually how I did it too, despite the existance of relations, but even there it requires code to look up IDs).

Right...you can create a combo box that's read-only, but it doesn't get rid of the down arrow.

>P.S. Another one I thought about, although I'm not sure if I'll use it in my current project, it would make a good topic for the help. If I wanted menu items File : Save, File :Revert (message sent to currently active window) what would be the way to handle this? ie..
>
> private void SaveMenuItem_Click(object sender, EventArgs e)
> {
> mmBusinessForm oForm = mmAppDesktop.FormMgr.GetActiveBusinessForm();
> if( null != oForm ) oForm.Save(); // or Revert, check IsChanged etc.
> }
>
>And probably handle the File menu's DropDownOpening event to enable or disable Save/Revert based on GetActiveBusinessForm().IsChanged()

Yes, that is the approach you would take.

>P.P.S.
>One other thing. The "Binding Source Selection" dialog (got from [...] button on BindingSource in the property sheet) only recognises this syntax:
>
> this.oXYZ = (XyzBizClass)RegisterBizObj(new XyzBizClass());
>
>and not the
>
> RegisterBizObj(oXYZ = new XyzBizClass());
>
>Could there perhaps be a way of defining available business objects using an attribute or something? The current implementation (scanning code) strikes me as a bit fragile.

You're right in that the BindingSource dialog is looking at a specific construct to include the object in the list. We are thinking through ways to open this up a bit. Originally the thought was that you should only list business objects that have been registered with the form since those are the only objects that are included in events, but we could offer an option to list all business objects. Note that if the object doesn't appear in the dialog, you can manually enter the business object in the BindingSource property.

Best Regards,