MDI Children and DLLs

L

lgbjr

Hi All,

I have a VB.NET MDI application with several MDI Child forms. Each of the
MDI Child forms has a significant amount of code. What I think I would like
to do is create a DLL for each child form, so that if I need to make changes
to a particular form, I can just update the DLL for that form and have the
user download just the new DLL.

From the main menu of the MDI parent, a user selects a particular task,
which generally involves processing information from a particular type of
file. The user selects the file using an OpenFileDialog. then I do a bit of
checking to make sure the file is the right type of file for the particular
task selected. If it is, I open the MDI Child form and pass the filename and
some other information to the form.

From this point, all processing is done from the Child form.

So, is it possible to take the entire form and put it in a DLL? Or can I
only take the form functionality (various subs and functions) and move them
to a DLL?

TIA
Lee
 
L

lgbjr

Hi Ken,

thanks for the reply. And thanks for the link. I see what he's doing and it
looks fairly easy to implement.

One question though. I don't see a way to pass information from the MDI
parent to the dynamically loaded form. I have a feeling this is a trivial
matter, but I'm not sure how to do it.

Regards,
Lee
 
L

lgbjr

Hi All,

To be more specific about my previous post:

Currently, in my MDI Parent Form, I have a public class with public shared
variables that are passed to the MDI child forms.

changing the Child forms to be dynamically loaded (ChildForm.dll), I can't
figure out how to pass the public shared variables to the form when it's
loaded.

Can I expose the public class with my public shared variables in the MDI
parent form to the childform.dll? Or, how do I pass the public shared
variables to the dll?

TIA
Lee
 
C

Cor Ligthert [MVP]

Lee,

This overlay approach was very nice in MS Dos computers. Your mdi forms are
seperated classes. If you use them right, than they will be consequently be
released by the GC. (With right I mean not creating everything in a shared
way)

The DLL's that you want to create are libarys as is by instance as well the
Net DLL and the MicrosoftVB DLL. The code taken from that will be included
in your exe.

For MDI is that not such a nice approach to create those librarys because
the change that you reuse them is very low. It can of course be a good
approach to create such a library for your own standard usercontrols,
templateforms or whatever.

I hope that this gives an idea

Cor
 
L

lgbjr

Hi Cor,

I agree with what you say. The only form that has anything declared as
shared is the MDI parent, and it is nice that once the child form (its own
class) is closed, GC takes out the trash.

I also understand that the purpose of a DLL is really for code that is
reused in many different locations, and that putting a form in a DLL is
contrary to this purpose, since the code for the form is only used by the
form.

My purpose for putting the forms in seperate DLLs is two-fold:
1 - Licensing and distribution - The application is really a compilation of
quite a few tools and depending on what the client purchases, I could reduce
the size of the install package by only including the DLLs for what they
purchased
2 - Upgrades - The MDI parent is not likely to change nearly as often as the
child forms. So, as I make changes to the functionality of a particular
child form, the client can download just a new DLL, rather than a much
larger executable that would include all of the code for all of the child
forms.

Make Sense?

Assuming yes, do you have some idea how I can pass variables from the MDI
parent to one of these dynamically loaded forms?

Thanks!!

Lee
 
C

Cor Ligthert [MVP]

Lee,

In my opinon describes this page your problem (Net is at the bottom)

I hope it helps something,

Cor
 
K

Ken Tucker [MVP]

Hi,

I would add a property to the forms stored in the dll to passed the
shared data.

Ken
 
C

Chris Petchey

Since a form which is an MDIChild has a property "MDIParent", if you
make the variables public properties of your MDIParent, and set a
reference in the mdichild project to the mdiparent, your mdichild would
be able to access the variables directly from the parent:

[mdiparentproject]
[mdiparentform]
public SomeVariable as string
public OtherVariable as integer
sub createchild
'do whatever
end sub
[end form]
[end project]

[mdichild project]
{reference to mdiparent project}
[mdichild form]
sub Form_Load(sender as object, e as eventargs)
dim MyParent as mdiparent.mdiparentform
MyParent=ctype(me.mdiparent,mdiparentproject.mdiparentform)
me.text=myparent.SomeVariable
end sub
[end form]
[end project]
 
L

lgbjr

Chris,

Thanks for the reply. Seems straight forward, but how do I "set a reference"
to the MDIParent project in the MDIchild project? I right click on
References, select Add Reference, the go to the projects tab and add a
reference to the MDIParent project? When I try this, it says that an
assembly must have a DLL extension to be referenced.

Am I missing something?

regards,
Lee

Chris Petchey said:
Since a form which is an MDIChild has a property "MDIParent", if you
make the variables public properties of your MDIParent, and set a
reference in the mdichild project to the mdiparent, your mdichild would
be able to access the variables directly from the parent:

[mdiparentproject]
[mdiparentform]
public SomeVariable as string
public OtherVariable as integer
sub createchild
'do whatever
end sub
[end form]
[end project]

[mdichild project]
{reference to mdiparent project}
[mdichild form]
sub Form_Load(sender as object, e as eventargs)
dim MyParent as mdiparent.mdiparentform
MyParent=ctype(me.mdiparent,mdiparentproject.mdiparentform)
me.text=myparent.SomeVariable
end sub
[end form]
[end project]
lgbjr said:
Hi Cor,

I agree with what you say. The only form that has anything declared as
shared is the MDI parent, and it is nice that once the child form (its own
class) is closed, GC takes out the trash.

I also understand that the purpose of a DLL is really for code that is
reused in many different locations, and that putting a form in a DLL is
contrary to this purpose, since the code for the form is only used by the
form.

My purpose for putting the forms in seperate DLLs is two-fold:
1 - Licensing and distribution - The application is really a compilation
of
quite a few tools and depending on what the client purchases, I could
reduce
the size of the install package by only including the DLLs for what they
purchased
2 - Upgrades - The MDI parent is not likely to change nearly as often as
the
child forms. So, as I make changes to the functionality of a particular
child form, the client can download just a new DLL, rather than a much
larger executable that would include all of the code for all of the child
forms.

Make Sense?

Assuming yes, do you have some idea how I can pass variables from the MDI
parent to one of these dynamically loaded forms?

Thanks!!

Lee
 
W

worstprogammer

Hi lee
you can try using static variables. I am not sure if its possible
or acctually do the tric but as all of the forms are basically class
this just might work.

thanks

w.P.
 
C

Chris Petchey

Compile the mdiparent project and use the browse button on the .net tab
of the add reference dialog

lgbjr said:
Chris,

Thanks for the reply. Seems straight forward, but how do I "set a reference"
to the MDIParent project in the MDIchild project? I right click on
References, select Add Reference, the go to the projects tab and add a
reference to the MDIParent project? When I try this, it says that an
assembly must have a DLL extension to be referenced.

Am I missing something?

regards,
Lee

Chris Petchey said:
Since a form which is an MDIChild has a property "MDIParent", if you
make the variables public properties of your MDIParent, and set a
reference in the mdichild project to the mdiparent, your mdichild would
be able to access the variables directly from the parent:

[mdiparentproject]
[mdiparentform]
public SomeVariable as string
public OtherVariable as integer
sub createchild
'do whatever
end sub
[end form]
[end project]

[mdichild project]
{reference to mdiparent project}
[mdichild form]
sub Form_Load(sender as object, e as eventargs)
dim MyParent as mdiparent.mdiparentform
MyParent=ctype(me.mdiparent,mdiparentproject.mdiparentform)
me.text=myparent.SomeVariable
end sub
[end form]
[end project]
lgbjr said:
Hi Cor,

I agree with what you say. The only form that has anything declared as
shared is the MDI parent, and it is nice that once the child form (its own
class) is closed, GC takes out the trash.

I also understand that the purpose of a DLL is really for code that is
reused in many different locations, and that putting a form in a DLL is
contrary to this purpose, since the code for the form is only used by the
form.

My purpose for putting the forms in seperate DLLs is two-fold:
1 - Licensing and distribution - The application is really a compilation
of
quite a few tools and depending on what the client purchases, I could
reduce
the size of the install package by only including the DLLs for what they
purchased
2 - Upgrades - The MDI parent is not likely to change nearly as often as
the
child forms. So, as I make changes to the functionality of a particular
child form, the client can download just a new DLL, rather than a much
larger executable that would include all of the code for all of the child
forms.

Make Sense?

Assuming yes, do you have some idea how I can pass variables from the MDI
parent to one of these dynamically loaded forms?

Thanks!!

Lee

Lee,

This overlay approach was very nice in MS Dos computers. Your mdi forms
are seperated classes. If you use them right, than they will be
consequently be released by the GC. (With right I mean not creating
everything in a shared way)

The DLL's that you want to create are libarys as is by instance as well
the Net DLL and the MicrosoftVB DLL. The code taken from that will be
included in your exe.

For MDI is that not such a nice approach to create those librarys
because
the change that you reuse them is very low. It can of course be a good
approach to create such a library for your own standard usercontrols,
templateforms or whatever.

I hope that this gives an idea

Cor
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top