Hi Terry,

I've had MM.NET since it was in beta; I might have been the first or second person to purchase it while in beta. But I haven't done that much with it, other than watch it develop.

What makes the framework interesting for me is that it is class-based, rather than template-based. This means that if I don't like a behavior, I can write code that changes it, and modifies my application, in place. And, of course, Kevin has done his homework, in spades. His book on .Net for VFP Developers is the best book I've read as an introduction to .NET (and my bookshelf is littered with such).

I wouldn't bother writing the code you want with the vanilla grid, as the result wouldn't be something that caused the customer's heart to beat faster. <s> Infragistics stuff, otoh, which I've also had since they started the subscription, is another matter. If you are going thin-client, it is almost (the javascript on the client is the "almost" factor) the holy grail.

A framework's job (I've been using frameworks in VFP for 8 years) is to take you 90-95% of the way; and make it as painless as possible to make that last 5 to 10% work the way you want it to. In VFP we have found that there is a sub-industry in going the last 5 to 10%, because 90% of the users want it to be 100% -- they are as much domain experts as anything else, and want a tool to articulate their domain knowledge into software.

I think the reason frameworks tend not to go the 100% is a factor called "range of convenience" in the psychology literature: we can only stretch our minds so far at one time. And that last 10% tends to be occupied with a multitude of small issues, most often connected to UI.

Once Kevin has the ObjectSpaces techology in MM.NET (an example of the large issues with which he has to deal), we plan to start subclassing MM.NET in order to meet our idiosyncratic needs. <s> We tend to be entirely metadata driven in VFP, including virtually all UI behaviors (dynamic enabled, dynamic enabledonlywhennew, dynamic enabledonlywhenunchanged, dynamic cascading field triggers, dynamic visible, lookup view/list definition, lookup filters, dynamic allow edits, dynamic allownew, dynamic allowdelete, dynamic allowview, all entity CRUD triggers, including pre-transaction and post-transaction), so that's what we'll be adding to our subclasses of MM.NET -- Kevin has put in the triggers (I think <s>), which allow us to approach this in a pretty straightforward manner, I hope. <s>

And then of course there are the builders, which are a PITA to create in .NET compared to VFP. I've begged Ken Levy for VFP's aselobj() or equivalent in Whidbey; and I know he planned to show off the builder framework to the Whidbey team (and it doesn't hurt that he wrote a major builder sub-framework, BuilderB, for VFP).

Anyway, the big thing for us is whether the framework is class-based, and does the major things right. MM.NET, and no other framework for .NET to my knowledge, does this. VFP has had OOP since 1994, and shipped with a framework (written by Yag, now of the VSData team) that was class-based. I suspect that decade has given VFP developers a chance to know what a framework should, and should not, do, in a way that only experience can teach.

Hank

>Hi Hank,
>
>Thanks for having an interest in this thread. I have used MM.Net for a couple of winform apps and like it very much but I'm just now feeling the growing pains of using it for Web apps.
>
>In message #909445 of this thread, Kevin says he is using Infragistics web control with MM.Net so I think if would work fine. I would be interested in hearing more from you about your experience with MM.Net and Web apps.
>
>Regards,
>
>Terry Carroll
>
>
>>Hi Kevin,
>>
>>reading this thread, I realize the only in it that matters to me is whether the Infragistics WebGrid etc. integration will allow in-grid editing. Will it?
>>
>>thanks,
>>
>>Hank
>>
>>>Terry,
>>>
>>>>I have worked long and hard trying to get MM to bind and bindback on demand. On initial page load I can control binding but on a postbacks none of the binding methods work. They all check for IsPostBack and if true exit the code. It would seem very strange to me if I’m the only one who has encountered this road block, so I wonder how they handled it!
>>>
>>>Typically you don't want a control to rebind during postback because it already contains the correct value (and rebinding would obliterate the value the user has entered)...that's why the checks are in there. That said, there are situations where you DO want this to occur, so you can simply call the form's BindControl method instead.
>>>
>>>Regards,