We have put considerable time into using Microsoft's UIAP which requires that you derive from a class that is derived from a Form class. This provides a MODEL-VIEW-CONTROLLER model for the GUI and very flexible navagation graph capability.

We have forms that we have developed that we would like to take advantage of your GUI approach to the business objects and data access.

It appears that your StandardForm must derive from a Form class also?

Is there a way to get this all to work? 

Yes, all StrataFrame Windows forms inherit from System.Windows.Forms.Form, so you could easily take MicroFour.StrataFrame.UI.Windows.Forms.StandardForm and inherit it to make a base form for your application. To use StrataFrame, you cannot escape the use of a StrataFrame form, even through the use of the StrataFrame UserControls and ThemedContainers because they still require the StrataFrame form to perform the databinding, etc. (there's just too much logic in the MicroFour.StrataFrame.UI.Windows.Forms.BaseForm that is required).



In case you're wondering, StandardForm inherits from BaseForm, and adds a slight bit of extra automation, but it's not required.

I have attached the source code that Microsoft provides for the UIAP. We have modified it, previously, to work in the 2005 framwork. If you review this you can see that it needs a Windows.Forms.Form class. I assume that once we get the source code we can change the Form to your Class that derives from Form and all will be happy, maybe.

For our application being able to configure the workflow of the forms from an XML file is so important, that we must get this to work for us to move on with the Strataframe-framwork.

My question: Is there a solution that will allow us to make changes to your framwork and rebuild?

Well, when you purchase the framework, you receive the full source code for all runtime components. We provide a solution containing the 4 source code projects that can be build right out-of-the box. However, 2 things might make you want to take a different approach than modifying our source code.



1) The StrataFrame source code is in VB.NET.

2) If we supply an update, your changes to the source code would need to be re-implemented in the updated source code.



So, your best approach, would be to take your classes and change their inheritance from System.Windows.Forms.Form to MicroFour.StrataFrame.UI.Windows.Forms.StandardForm. So, WindowsFormView declaration would change to:



public class WindowsFormView : MicroFour.StrataFrame.UI.Windows.Forms.StandardForm, IView



Then, you get the best of both worlds, and that inheritance statement would be the only code change required (you'll just have to add a reference to the StrataFrame assemblies in the UIPA project before you build it). The UIPA source code is less likely to change than our source code.

Sounds like a great solution and I will work on it and post back the results to inform others who may want to do this.

Thanks for your responsive feedback.

Aye, let me know how it works.

I wanted to give you the results of my changing the UIPA to derive from the Standard form.

It looks like this:

public class WindowsFormView : StandardForm, IView

It builds, but I get two warnings:

base type MicroFour.Strataframe.UI.Windows.Forms.BaseForm is not CLS compliant.

Any idea on the severity of this?

Also I added three references to Microfour base, business and UI from the GAC. When your using standard form what are the minimum references you need?

This message doesn't matter unless you are planning on using some COM+ interaction.  The message will not cause you any problems. To remove the message, add the following tag to your AssemblyInfo.cs file.

[assembly: System.CLSCompliant(false)]

This will prevent the message from appearing.  Just for a reference, most any CLS compliance is for a cross-platform type of functionality on data types.  The reason you get this message is because there are certain methods that return a specific data type that is not a primitive data type.  If you are creating CLS compliant COM+ DLLs, this still will not cause you any issues, because these internal methods will not be called externally anyway.

Hope this helps.