Reflection works well for creating a modular program. I would recommend using strong types more liberally. I assume VB allows you to call methods on an Obj that do not exist and that it will use reflection to call those methods. It would be better to cast your object into a Form. Here is the C# syntax (sorry, I don't know VB.NET syntax for casting...):
----> Object ProgObj; Form ProgForm; ProgObj = Activator.CreateInstance(ProgType); Form ProgForm = (Form) ProgObj; ProgForm.MDIParent = mvarMDIMain; ProgForm.Show(); <---- If ProgObj is not really an object, you will get a cast exception which you can catch. Strongly typed method calls perform better and will catch more errors at compile time rather than run time. -- Peter > Jay Ayliff spake: > > Hi List, > > I want to run a development technique past the experts in the list to get > comments and suggestions: > > We need to write a large and extensible application using WinForms. I have > worked out a design strategy but would appreciate any commentes from the > experts in the list. The idea I have in mind is to have a > container program > coded as an EXE, based on an MDI form. This will not do any application > processing but will load and run the other programs. These will > be coded as > single classes inheriting from System.Windows.Forms. A number of these > classes can be compiled into a single DLL assembly which can be put on an > Intranet web server. The code to load and run the form in the DLL is as > follows: > > > Dim ClassName As String ' Name of the class to be instantiated > Dim AssemblyFileName As String ' URL where we look for the > assembly > Dim AssemblyName As String ' Name of the Assembly > Dim Assem As System.Reflection.Assembly > Dim ProgObj As Object > Dim ProgType As Type > > ' For the sake of demonstration, set these values explicitly. > ' In the real app they will be read in from a database > AssemblyFileName = "C:\VBDotNet\TestProject\bin\TestProject.dll" > AssemblyName = "TestProject" > ClassName = "MyForm" ' MyForm is a class in TestProject inherited > from Windows.Forms.Form > > Assem = > System.Reflection.Assembly.LoadFrom(AssemblyFileName) ' > Load the assembly > ProgType = Assem.GetType(AssemblyName & "." & > ClassName) ' > Get the Type > ProgObj = Activator.CreateInstance(ProgType) ' > > Create an Instance > ProgObj.MDIParent = mvarMDIMain ' Put it in as a child > of the MDI form... > ProgObj.Show() ' ... and show! > > > I have found this to work, and it seems to have enormous possibilities: > - We can group logically related applications in the same DLL assembly > - We can easily implement new versions of apps by either overwriting the > DLL assembly or simply by changing the value of AssemblyFileName so the > program looks in a different place for the new version. > > I am happy about other aspects of this development, e.g. passing data > between the loaded form and the container. What I really want a warm > feeling about is whether this use of System.Reflection is a viable way of > creating an extensible application, or whether I am storing up trouble for > myself further down the line. I await your gracious comments. > > Regards, > > Jay Ayliff > Stalis Ltd You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
