Possible? Import a form through an interface

Hi,

My current project is Managed Extensibility Framework, its up and running as a test fornow and i can import no problem the interfaces are good, but i have a problem with how can i present a ui with an imported dll.

lets say i have a dll that needs a path, i dont want to clutter my main program with an infinite number of textboxes etc to cater for any of my dll's, i would like them to have there own mini forms, is that possible.

i know i could use dialogs and inputboxes or even create a form on the main program that keeps certain settings like usual save paths, places to check for loading files etc but i thought it would benice for each dll to have its own.

thanks

or if thats not possible could i create controls on blank formand remove them as needed?, this idea seems very possible

The title of this thread doesn't make any sense at all. An interface is just that; an interface. It's a contract that a class can implement but the implementation is then in the class not in the interface. So an interface itself doesn't contain any implementation or code.

However since you're using MEF I assume that you've put all the interfaces that the extensions need to implement into its own assembly project? Since the extensions needs to set a reference to that. In other words that these are really separate from your main application. If that is the case you can easily add a class into that class library and have methods that creates and displays the various forms you want to display. You can even add the Forms so you can use the designer to design them or you can create them on the fly.

Code:

---

Public Sub ShowSimpleForm()
  Dim dlg As New Form
  Dim button As New Button
  button.Text = "Hello"
  dlg.Controls.Add(button)
  dlg.ShowDialog()
  dlg.Dispose()
End Sub

---

However it's of course much easier to add the Form itself and use the designer and just create an instance of that form in the above method. In either case you need to add a reference to the Microsoft.Windows.Forms to your class library.

Hi

I wasnt sure how to explain it, i just dived into MEF a couple of days ago, there is lots of loose info in my head right now :) sry.

anyway thanks ill give your suggestion a go.

my interfaces are still in the main project, but i can easily move them out there is only 3 right now.
just to clarify

ill seperate the interfaces along with the class that is used which selects the extensions to use(RIGHT)? and the class that does the composing ill keep with the main project.(LEFT)

Attachment 100019

and then setup a directory catalog the the new project?

and then i can create a form and call it through the interface like : Interface.Showform (which is a sub that shows the form)

No, the Interface can not have any code that shows the Form, a class however can. As I mentioned earlier an Interface doesn't have any code at all.

Interfaces are not new to MEF. They are simply an abstraction, and for that reason, they don't have anything other than a template for what something is meant to be as Joacim is saying. You would have to use a class. If you want to understand how interfaces work, and what they are used for, there's a few links on MSDN, but since an interface also applies to other languages, conceptually, you should be able to use that information from people writing about it for other languages too. For instance, C++.

It's like having a blueprint for a parts list and asking somebody to return a built vehicle out of nothing. ;)

sorry ill clarify

i understand interfaces, im not saying change any interfaces, what im asking is, will i move the interfaces into another module on the newproject, and then will have to move the move the class i showed above to that project and then will i just create forms for each interface

example
i have an interface

interface Interface1
sub1(myvar as string)
end interface

then obviously anything using that must have a sub1 which needs a variable so my form will provide the opportunity to provide that variable

now since the exports need to be imported, ill have to also include the class that does the importing is that right,

im just asking because i will have to rearrange everything and im new to this i only put it together yesterday. :)


this is the class that imports the parts(this class is also a part itself if im not mistaken)

Code:

---

<Export(GetType(IGetPart))>
Public Class clsGetPart
    Implements IGetPart

    <ImportMany()>
    Public Property ImportedModules As IEnumerable(Of Lazy(Of IPart, IPartData)) 'MEF finds exports based on type,if no type is given  the propert type will be assumed

    Public Function GetPart(ByVal input As String) As List(Of String) Implements IGetPart.GetPart
        GetPart = New List(Of String)

        GetPart.Add("Looking For Part")
        For Each item As Lazy(Of IPart, IPartData) In ImportedModules
            If item.Metadata.PartID = input Then '!!!!!!!!!!!!!!!!!!!!!!CHANGE THIS LATER!!!!!!!!!!!!!!!!
                GetPart.Add("Part Found")
                For Each item2 As String In item.Value.RunPart(input)
                    GetPart.Add(item2)
                Next
                Return GetPart
            End If
        Next
        GetPart.Add("Error!! Finding/Running Part")
        Return GetPart
    End Function
End Class

---

these are the interfaces ill need to move only 2 to another project since one is used by the main app, IGetPart interface

Code:

---

Public Module modInterfaces
    'IGetPart is used to for the class that finds a specific part
    'IPart is used to reference the Part and run it
    'IPartData is used to get the part ID for the contract

    Public Interface IGetPart
        Function GetPart(ByVal input As String) As List(Of String)
    End Interface
    Public Interface IPart
        Function RunPart(ByVal Input As String) As List(Of String)
    End Interface
    Public Interface IPartData
        ReadOnly Property PartID As String
    End Interface

End Module

---

and this will stay on the main program

Code:

---

Public Class clsFillCatalogs
    Dim MyContainer As CompositionContainer 'holds parts and performs composition(imports/exports)

    <Import(GetType(IGetPart))>
    Public Property GetPart As IGetPart

    Public Sub New()
        'An aggregate catalog that combines multiple catalogs
        'Adds all the parts found in the same assembly as the Program class
        'adds parts found in  a directory
        'Create the CompositionContainer with the parts in the catalog
        'Fill the imports of this object



        Dim tmpReport As New List(Of String)

        Try
            Dim catalog = New AggregateCatalog()
            catalog.Catalogs.Add(New DirectoryCatalog(Windows.Forms.Application.StartupPath & "\Ext"))
            catalog.Catalogs.Add(New AssemblyCatalog(GetType(clsFillCatalogs).Assembly))
            tmpReport.Add("Catalogs Found = " & catalog.Catalogs.Count.ToString)
            MyContainer = New CompositionContainer(catalog)
        Catch ex As Exception
            tmpReport.Add(ex.ToString)
            ReportToForm(tmpReport)
            Exit Sub
        End Try

        Try
            MyContainer.ComposeParts(Me)
            tmpReport.Add("Part Composition Successful")
        Catch ex As Exception
            tmpReport.Add("error Composing Parts")
        End Try
        Form1.PartList.DataSource = MyContainer.Catalog.Parts.ToList ' !!!!!!!!NEED TO PARSE THE GETPART CLASS FROM HERE!!!!!!!!!!!!
        ReportToForm(tmpReport)
    End Sub

    Private Sub ReportToForm(ByVal tmpReport As List(Of String))
        Form1.ReportList.DataSource = tmpReport
    End Sub
End Class

---

its only skeleton code so no remarks :), but is what i said earlier they way i will do it

I'm a little confused now, if the question has changed or is still the same. By my understanding you are having issues with this in sum:

Quote:

---

Re: Possible? Import a form through an interface

---

By the feedback you have been given, it's not possible to do that, and for the reasons given above. However, If you have a class that can inherit from the interface that you want to use, then it is possible. So that's all you really need to achieve here. :)

So, is the real issue here about being able to use the interfaces from somewhere else? Or implementing from an interface?

You basically just threw all the code you had at us, but I don't quite understand your question.

I'm not clear on what you expect to have where. Heck, I'm not even clear on how many different projects you are talking about, nor what will be in each project. It seems like there would be three:

1) A dll that just contains interfaces.

2) A main project that is in some way different from #3, but references #1.

3) Some other project that references #1 and contains classes that implement interfaces found in #1.

Is that right?

yes perfect, shaggy hit the nail :)

i now have three projects, following mr joacims advice to have a form for each interface

i have main the main program which has an interface with the PartServer(which basically gets specific parts) which then has the interface with the parts

here

Attachment 100025

just going to test it all see if its working

If Shaggy is right then:

Quote:

---

3) Some other project that references #1 and contains classes that implement interfaces found in #1.

---

You only need a reference to 3) to use the classes which already have a reference to the interfaces they are implementing.

yea do think i have a references problem, because its giving my a null object error and asking for the new keyword, the getpartclass isnt being instantiated(probably becase i didnt use new....) and i can access it directly :/ how do i get around this,

MainProgram.clsFillcatalogs has an import which is surposed to get PartServer.clsGetParts through the interface <Import(GetType(IGetPart))>Public Property GetPart As IGetPart

IgetPart is located in the mainprogram assembly

when stepping through the catalogs are not getting anything either there getting an error saying they cant find anything useable, which i assume is causing the problem.

assuming all syntax is correct since it was working before i moved everything, any ideas

im going to start a new project and start from scratch to be sure everything is right.

But if I understand you correctly IGetPart is one of the Interfaces you have for MEF, those where the ones I told you that you should move.

Why do you have your interfaces inside a module? If you want to have a different namespace then use namespace not module.

The whole reason I suggested that you move everything is so when you or someone else starts to write extension dlls for your application they need to reference these interfaces. If you then in the same library also have some helper classes that the extensions can use then that's great, such as a class which can show various dialogs and forms that the extension might want to take advantage of and use. That part is not really about MEF it's just plain and simple OOP.

I think i messed up when i was separating everything, well it wasnt working so it went wrong somewhere.

i put it back together like it was initially. so i have 2 projects now, the main program which has everything in it and the project with the parts/classes that will be imported.

so with your idea before your saying ill just move the interfaces that the extensions will use into another project?

so ill have
-main program
-extension classes
-Interfaces

then ill reference interfaces from the extensions project, and then reference the main program from the interfaces project

the interfaces project will be a windows project too?



i hope this is right.

when i started this project it seemed so big, and confusing but it seems its shrinking in my mind, which is good, i think im learning something :)

ill test this out anyway.

No you will reference the interface library from both your main application and your extensions. If you want to provide additional code that can be used in your extensions then that code should go into the same library as the interfaces.

ok i got it, thanks ill try it out.

The interfaces will be in a class library. That library is then referenced by the main project, the extention project, and any other extension project you feel like writing later on. By doing this, the main project won't know anything about the classes in the extension project, and that's how you want it. All it will need to do is look at the objects in the extension projects and see whether or not the objects implement one or more of the interfaces. If they do, then the project (the main project, most likely), will be able to create an instance of that class, without knowing what the class is, and cast it to the interface. The main project can then work with this other class, regardless of what it actually is, via the interface. It won't have any knowledge of, or access to, non-interface members, so the interface has to provide all the functionality that the main project will need, but since the main project won't need to know about the class aside from the interface, the main project doesn't have to have a reference to any of the extensions. Better yet, more and more extensions can be written with different classes and functionality, and the main project doesn't need to know about them.

Hi

my 'main' project is really just going to be for selecting and report the progress of the extensions, and im hoping to have (at the moment) 1 interface project with the interfaces it needs for the extensions, example, an interface with sub(var as type) and another with sub(var1 as type, var2 as type) etc etc and then having a ui for each interface, the input to start with will just be paths and filenames and later i may add another interfaces project to cater for manual file data manipulation etc im not sure how i will go about that yet, im just trying to get a feel for the basics for now.

by the way my aim with this MEF project is creating all the functions anyone could possible need with excel and word, parsing, merging, sorting, changing filetypes etc. since i find myself writing similar applications over and over again i thought this would be perfect for me.

i know why it wasnt working before,

in the interfaces project the composition helper was an exported class which had an interface to the main program project

thats why i couldnt do anything other than use the method declared in the interface, for some reason thats how the tutorial on microsoft did it. but i found another one that didnt interface with the composition helper it instantiated its class instead,
i think the microsoft example did it in a way you can import several composition class's as well as getting extensions imported for each composition.

im just doing it now, hopefully its gonna work this time

I know nothing about MEF, so meh!