Compile Form to DLL

[Mike_R]

This "FormDll1" would be the equivalent of the one I said I wanted to reuse. is that right?

Yes, the 'FormDLL1' is the name I gave the Class within the 'vbBlankClassLibrary.dll'.

 

 

I used the inheritance Picker to try to use the form in another project.

 

Why was it named "FormDLL1" originally, but when looked for it in the directory to pick it, it showed up "as "vbBlankClassLibrary.dll"?

I'm not quite sure what you mean by "inheritance Picker"? I guess you mean Alt|Project|AddReference...?

 

The reason it shows up as 'vbBlankClassLibrary.dll' is because this is what I named the Class Library (the DLL). Look in the Solution Explorer, you'll see the 'WindowsApplication1', which is the Startup Project (the EXE) and you'll also see 'vbBlankClassLibrary' which is the Class Library (or DLL) Project.

 

The 'FormDLL1' is the name I gave to the Class/Form that resides within the 'vbBlankClassLibrary'.

 

 

Then in the inheritance picker it was called:

 

Component name: "FormDLL1"

Namespace: "vbBlankClass library"

 

I was looking for "FormDLL1" and it wasn't there. How do you know what you're looking for?

Ok, maybe say the "Inheritance Picker" you mean the "Object Browser"?

 

Anyway, you just stated that it read:

Component name: "FormDLL1"

and then state "I was looking for "FormDLL1" and it wasn't there.". It sounds like it was there, no?

 

Also the "Form1" from the original Windows application did not seem to be available to be picked. Not that I wanted it, but why is that?....

The Form1 will be available within the Project (Namespace) it originates. In this case it will be available within the 'WindowsApplication1' only.

 

 

Why is it that your download saved forms in a manner that could be inherited, but mine did not?

I don't know. Forms/Classes are inheritable by default. Are you sure you want to be Inheriting Forms though? Visual Inheritance is supported in VB.Net, but are you sure you want to be doing that? Do you want to be able to Call the Form that resides within your DLL, or do you wish to Inherit from it?

 

 

I have 6 books, I've read the majority of them . It seems like its either simple stuff that I understand easily, or it's nuts stuff. As if there's a big hunk of intermediate stuff missing. I don't know why, but it just ain't clickin'

It sounds to me that you must have burned through your books a bit too quickly. You might want to go back to the VB.Net book that you like the most and re-read the chapters on Classes, Objects, Inheritance and Forms.

 

It feels to me that you are doing ok, actually, it just sort of feels like your shoe laces were untied and you got yourself all tangled up... Take it slow and I think you'll work through this. Once you have the basics down of how to start a Project and Add References, etc., I think you'll be ok...

 

-- Mike

[realolman]

It's obvious that I am unfamiliar with the terminology. And there certainly is a plethora of it.

 

What I want to do in this case is make a small form with buttons and textbox to gather numerical input, and be able to use it again in other situations... Maybe change it slightly to include an upper and lower limit, or something like that.

 

When I was reading one of my books the chapter on inheritance seemed like the thing. As a matter of fact, I decided to try to make this form sort of as my own exercise ... something I thought might be useful for myself using principles from the chapter.

What the author did was make a little form, inherit it, make a change, and then had two forms, similar, but different.

 

Project \add inherited form \add new item will get you to the inheritance picker

 

To me, I can't see much point in inheriting forms from the same project. It seems to me it would be much more useful to be able to save them and use them as individual components when you wanted them. Isn't that supposed to be a big deal advantage of OOP?

 

Anyway, apparently you can't inherit .EXE s... they gotta be .DLL. Also apparently, VB.net Standard won't save as a DLL. I don't know if any of that is true. I'm a .net rookie. But, if I was to complain, I would say that is an arbitrary distinction that just makes things more difficult than they would have to be. Why shouldn' I be able to point and click anythiong I want, and have the software figure it out? You know all the stuff you went through to show me this. Should that all really be necessary?

 

Maybe I don't want to inherit... I don't know. I just wanted to reuse a form.

Thanks for all your help (which was considerable)

[Mike_R]

Inheriting a Control is more normal... Inheriting a Form is "ok", but a little less usual.

 

Let me give an example of where I might use Form Inheritance:

 

(1) Let's say that I use some Subclassing to better control some of the Events that a Form has, or how some existing Events behave. (Don't worry about what is "Subclassing" at the moment, it just lets you change how a Form or Control behaves, but it usually involves a fair amount of work.) So you use Subclassing and effectively give your form a new "Event" that was not natively provided by MSFT. So far so good...

 

Now to use this in all your Forms you have two choices:

 

(a) Copy-paste in this code any time you wish to make use of this feature, or

 

(b) Have other forms Inherit this Form. :)

 

Obviously, choice (b) is cleaner and easier. And this is the point of Inheritance.

 

(2) Scenario 2 gets into "Visual Inheritance", which sounds more like what you are doing. I'm not such a big fan of this. The idea is that you add Controls or Labels to a Form. Now any Form that Inherits from this Base Form will automatically have these Labels and Controls already on it.

 

You can play with this, but I think that it gets pretty ugly. It can be ok if you want to create a standard "banner" or letterhead or the like on a set or suite of forms that can all inherit from this base class form that already has this formatting set... But once you start adding controls to the base form it can start getting messy fast. But it can be very useful, here's a Tutorial:

 

Visual Inheritance Using VB .NET Standard - Part 1

Visual Inheritance Using VB .NET Standard - Part 2

 

However, one does not have to use Inheritance to make a Form re-usable. You can make a form that has a set of controls on it and then give it a property that gives it's result...

[Mike_R]

Ok, let's continue with our little example and make the form into a true "Dialog Box". This form will be reusable in the sense that when it is called, when done, the Form will hold a value that the Caller can check.

 

For instance, this could be Form that allows the User to enter his Name and then hit OK. To make it re-usable, and not "hard code" what this Form is intended to do, we'll give this Form the ability to let the Caller change the message via a new property we'll call the .Instructions property.

 

The Caller will be able to get the results from a Property we'll call the .ResultString property.

 

Your program could then call this Form using somthing like:

Dim frmDialog As New vbBlankClassLibrary.FormDLL1
frmDialog.Instructions = "Please enter your name."
frmDialog.ShowDialog()
Me.Label1.Text = frmDialog.ResultString

How's that for re-useable! The key is that the Instructions are not hard-coded. :)

 

To make this possible, we do the following:

 

(1) Add two buttons to the bottom of our FormDll1. We give them the programmatic names 'btnOK' and 'btnCancel'. We set their .Text properties to "OK" and "Cancel", respectively.

 

(2) We then find the DialogResult property within the Properties Window and set the btnOK's value to 'OK' and we set the btnCancel's value to 'Cancel'.

 

(3) We then use the following code:

Public Class FormDLL1
   Inherits System.Windows.Forms.Form

   Private _instructions As String
   Public Property Instructions() As String
       Get
           Return _instructions
       End Get
       Set(ByVal newValue As String)
           _instructions = newValue
           Me.Label1.Text = newValue
       End Set
   End Property

   Private _resultString As String
   Public ReadOnly Property ResultString() As String
       Get
           Return _resultString
       End Get
   End Property

   Public Sub New()
       ' Required Calls:
       MyBase.New()            ' <-- Required Call
       InitializeComponent()   ' <-- Required Call

       ' Our Code:
       Me.Instructions = Nothing
       Me._resultString = Nothing
       Me.TextBox1.Text = Nothing
       Me.AcceptButton = Me.btnOK     ' <-- If User hits <Enter> key
       Me.CancelButton = Me.btnCancel ' <-- If User hits <Esc> key.
   End Sub

   Private Sub FormDLL1_Load(ByVal sender As Object, _
                             ByVal e As System.EventArgs) _
                             Handles MyBase.Load
       Me.Label1.Text = Me.Instructions
       Me.TextBox1.Text = Me.ResultString
   End Sub

   Private Sub FormDLL1_Closed(ByVal sender As Object, _
                               ByVal e As System.EventArgs) _
                               Handles MyBase.Closed
       If Me.DialogResult = Windows.Forms.DialogResult.Cancel Then
           ' If User hit Cancel, report Empty String as the User's reply.
           Me._resultString = Nothing
       End If
   End Sub

   Private Sub TextBox1_TextChanged(ByVal sender As Object, _
                                    ByVal e As System.EventArgs) _
                                    Handles TextBox1.TextChanged
       _resultString = Me.TextBox1.Text
   End Sub
End Class

Note that to create the above I had to pull the Sub New() out of the #Region "Windows Form Designer generated code" and then add our code to it.

 

Look through the code, I think you should be able to understand it. (Even easier within the attached project so that you can trace through it within the IDE.) But the basic functionality is that the Caller sets the .Instructions() and gets the .ResultString() when done. Because the .Instructions() is a set-able property, this form is quite re-usable.

 

We could even create real-time feedback/interaction via Events, Delegates or Interface-based callbacks. I know that that sounds daunting, but understand this code first, and then I can show you how to add an Event, it's actually very easy.

 

-- Mike

vbBlankClassLibrary.zip

Edited February 28, 2005 by Mike_R

[IngisKahn]

I'm using Visual Inheritance in a project I'm working on now. I have properties windows for a hierarchal set of objects. Really makes things easy. Combined with a FlowPanel (.NET 2.0) it saves alot of time.

[Mike_R]

Sounds very cool... And what's "Flow Panel"?

 

Still, I think that Realolman needs to be able to walk before he can run.

[realolman]

.

 

FormDialog is a new instance of vbBlankClassLibrary.FormDLL1?

 

 

 

I understand this enough to follow along but everything in this .net business seems so independent and out of order that I don't know if I could do it... although it doesn't seem a whole lot different than doing multiple forms in VB6

 

You made both forms in the same "solution" (God I hate that word)

Is that right?

 

If you wanted to use FormDLL1 in a different solution. How would you do that?

 

I guess maybe that's what I was getting at when I was blabberin' about inheritence

 

What is the Sub New() ? Does this execute before the Load event?

[Mike_R]

FormDialog is a new instance of vbBlankClassLibrary.FormDLL1?

Yes. Believe it or not' date=' this is exactly how it works in VB6 as well. The difference is that VB6 [i']cheats[/i] and has hidden code behind the scenes (that you don't ever see) that looks something like this:

Dim Form1 As Form1
Set Form1 = New Form1

Then within your code, you simply call stuff like Form1.Show(), etc without ever having to explicitly create an instance of it, because it was done for you behind the scenes.

 

Let me put it another way: Forms are Classes. So they must be instantiated before they are used.

 

 

What is the Sub New() ? Does this execute before the Load event?

Yes, you got it! :) All Classes have a Sub New(), which is called whenever a New Class is created. Since a Form is a type of Class, it also has a Sub New().

 

It does execute before the Load event, correct. Within a Form Class you should think of the Sub New() as replacing the Form_Initialize() event that used to exist in VB6.

 

 

I understand this enough to follow along but everything in this .net business seems so independent and out of order that I don't know if I could do it... although it doesn't seem a whole lot different than doing multiple forms in VB6

It's actually all 100% parallel. You've probably hit on almost everything that's different at this point. That said, reading your VB.Net's chapter on Form's and Controls could help too.

 

You made both forms in the same "solution" (God I hate that word)

Is that right? If you wanted to use FormDLL1 in a different solution. How would you do that?

Yeah, "solution" is pretty weak, eh? It's the equivalent of what VB6 called a "Project Group". Anyway, the EXE and the DLL within this Solution are in no way bound to each other. The "solution" is just a convenience for the programmer to see the code within the source DLL and the EXE at the same time. The key to the functionality rests within the fact that the EXE has a Refernce set via Alt|Project|AddReference... to the DLL.

 

To test this out, create a brand new Windows Application and then goto Alt|Project|AddReference... and then Browse until you find the vbBlankClassLibrary.DLL. Once you do this you will be able to utilize the Classes within that DLL in exactly the same way. :)

[IngisKahn]

what's "Flow Panel"?

 

It's a panel that arranges it subcontrols intelligently. So when you resize the form or add controls dynamically the controls are layed out nicely.

[Mike_R]

Nice. :)

 

I can't wait until 2005 is finally a full-release...

[realolman]

Hey Mike R.

 

thanks

[Mike_R]

No problem. :)

[realolman]

The two links in post 28 are right on the money.

 

He explains why you can't save a class library with VB.net standard and then shows how you can do it by using VBC.

 

VBC and it's use was in the book "Object Oriented Programming with Visual Basic "recommended by Danaes in another thread.

 

Danaes read it on a long bus trip. Either he took a bus to Neptune or he's a better man than I am. ( I think the latter )

 

It aggravates me that I have to mess around in the DOS command prompt screen. but I guess... like the guy says in the article, it saves you 600 bucks.

[Mike_R]

That advice is fine, and it's worth knowing a bit about the compiler options... But there's no need for that much hassle. All you need to do is this:

 

DLL/ActiveX project template for VB .net Std ed

 

Also, the 1st Project I send you in Post #8 is a perfectly valid blank Class Library Project. Just keep a copy of this around. When you need a new Class Library project, just copy the entire folder to a new location and then rename it as needed. :)

[realolman]

I made my little calculator type form. Saved it and edited the vbproj file as Mike R. said with Notepad and was able to use it in another project ...

 

it works!

 

This is one small step for most of you guys... one giant leap for me.

 

In Mike R.'s example, he calles the second form with ShowDialog and then when the second form closes it returns to the same sub it left.

 

I would like to not close the second form.

 

I can put a button on the calling form and that works... the variable is available to the calling form, but I'd like have the variable passed with an enter button on the called form, or maybe in the program.

 

How can you manipulate stuff on one form from a different form?

Edited March 4, 2005 by realolman

[stustarz]

One of the most commonly asked questions on this forum i think :)

 

Its all to do with exposing the properties and methods of your form class to allow the other form class to manipulate them.

 

You must instantiate an instance of your form then you can access any of its properties and methods (as long as they are set to public or friend).

 

For example to open another form from one form we do this:

 

Dim frmMyOtherForm As New MyOtherForm
frmMyOtherForm.Show()

 

If you wanted to access the publically exposed members etc on the other form simply use the declared instance of the form and modify the property you desire:

 

'We must create an instance of the class (a form is a class afterall)
Dim frmMyOtherForm As New MyOtherForm

'If using Visual studio, intellisense will display all the publically exposed 
'methods, properties etc that we can access

frmMyOtherForm.Text = "Some Text"

[stustarz]

Seeing as im in a very good mood right now :) he he. Heres a small demo app i made for a program of mine....

 

Basically demonstrating how to open forms from other forms and manipulate controls, using events.

 

Hope you'll find it useful

How To - Use Multiple Forms.zip

[realolman]

Thank you stustarz.

 

I ran your example. I'm sure it will shed some light.

 

I got a big kick out of your location when I saw it earlier.

 

If I'm ever in your neighborhood, Ill stop in and thank you personally