Gess Man wrote:
Can one create subforms in vb 2005 like one can in ms access If so, how can this be done
Hi Gess Man,
Are you meaning MDI as in Multi-Document-Interface
If yes then try this.>>>>
Public
Class Form1
'The following highlighted line should be one line of code in your code window.>>>>
Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
Me.IsMdiContainer = True
Me.Size = My.Computer.Screen.WorkingArea.Size
Dim Form2 As New Form
Dim Form3 As New Form
Form2.MdiParent = Me
Form3.MdiParent =
Me
Form2.Show()
Form3.Show()
End Sub
End Class
Regards,
S_DS
Personally, I haven't used Access in years; can you give an example of what a 'sub-form' is Perhaps describe what is to be achieved: maybe the architecture already exists.
If you mean forms that can be used as a sort of dynamic panel, sure. It's called a custom control. You basically create a new Custom Control for each "subform" you want, then drop those controls onto your main form like you would a text box or a datagridview.
You can build your custom controls of any combination of regular controls, so it really is just like a form, but it can be treated like a control.
It's hard to explain what an Access subform is to VB'ers who in turn can't explain a near equivalent or workaround. I am only a moderate with both VB and Access but feel capable to explain a bit to both parties.
A subform in Access in a form but it behaves in a special way when related to a parent form. It is NOT like an MDI form. Think of 2 recordsets in a parent-child relationship, or one-to-many. The parent form may show one parent record at a time. When you move from record to record on the parent form, the subform moves automatically moves to the related child records on the child form (subform). While the subform is a form object in its own right, the parent form interacts with it through a subform control. The key to the Access subform is the link relationship property which relates the parent to child.
As mentioned, this is not like MDI. Visually it has the same affect as having a panel with multiple controls in a VB panel. Make the panel invisible, and all it's child controls are invisible to the main form. What's lacking is the automatic record movement in the controls in the panel.
While a subform can appear like a datasheet, it can also be freestyle. However, if the subform is told to display as a datasheet, the the VB equivalent would be a form (the parent) and a datagrid control (child).
It was nice that Access took care of much of the overhead and record navigation. Made it quite easy.
Okay, I see. You will have to build that functionality yourself - it isn't automatically there, as it isn't really a globally common function. However...databinding of the controls comes to mind. So, it can be done with minimal coding.
Swade.
Can you give an example.
Sorry about taking so long to follow up....
As an example, suppose you have an "employee" class which has some standard properties (First Name, Last Name, etc...) then you would have to bind them all to the class properties..... ugh.
Suppose you use this class across multiple forms (create new user, view user, etc....) Lots of text boxes, lots of binding, lots of work with the IDE.
Instead, you simply create a custom control that would work as a "template" for the class. It would give you a GUI for the class, and if coded with non-readonly properties, could be used to edit that class. Basically, you design a "subform" that contains the text boxes and binding already in it.
Then, for each new form, instead of adding dozens of text boxes, you just add the custom control that already has them all in it.
Plus, it inherits from Forms.Controls, so you can do the things like Focus, Hide, visible, enabled, etc....
Swade wrote:
Sorry about taking so long to follow up....
As an example, suppose you have an "employee" class which has some standard properties (First Name, Last Name, etc...) then you would have to bind them all to the class properties..... ugh.
Suppose you use this class across multiple forms (create new user, view user, etc....) Lots of text boxes, lots of binding, lots of work with the IDE.
Instead, you simply create a custom control that would work as a "template" for the class. It would give you a GUI for the class, and if coded with non-readonly properties, could be used to edit that class. Basically, you design a "subform" that contains the text boxes and binding already in it.
Then, for each new form, instead of adding dozens of text boxes, you just add the custom control that already has them all in it.
Plus, it inherits from Forms.Controls, so you can do the things like Focus, Hide, visible, enabled, etc....
Hi Swade,
I guess you mean a CLASS that
Inherits System.Windows.Forms.UserControl
like this one.>>
To everyone else, go to the PROJECT menu and select ADD CLASS and PASTE this code in.
Run the code once and when you stop it MyCustomControl will be in the TOOLBOX.
Drop one on a FORM then look at its properties window.
You will see FirstName and LastName in there. :-)
Public
Class MyCustomControl
Inherits System.Windows.Forms.UserControl
Private _first As String
Private _last As String Public Property FirstName() As String Get Return _first End Get Set(ByVal value As String)_first = value
End Set End PropertyPublic Property LastName() As String Get Return _last End Get Set(ByVal value As String)
_last = value
End Set End PropertyEnd
Class
rather than one which
Inherits System.Windows.Forms.Form
The example at>>
http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=2503350&SiteID=1
uses
Inherits System.Windows.Forms.Form
Regards,
John