Input form basics-VBForums
Results 1 to 6 of 6

Thread: Input form basics

  1. #1

    Thread Starter
    Fanatic Member
    Join Date
    Feb 2013
    Posts
    899

    Input form basics

    Hi..

    i regularly build input forms and i seem to change the way i do it every time i do it.....

    it usually consist of declaring the form, setting properties or calling a function/sub that does the same... and them returning or storing a value afterwards whether everything went OKor not.....

    im just wandering how its usually done.....


    so for example i have an 'Add' something button that brings up a form that allows a user to add something to a DB..... im in the habit of using this same form to 'Add'/'Edit' data. it never causes me a problem im just thinking what is the norm?

    for an example i might have something like this......


    Code:
    Public Class frmUsers
    
        Private EditMode As Boolean
    
        Private UserID As String
        Private Name As String
        Private Surname As String
        Private AccessLevel As String
    
        Public Sub ShowForm(IsEditMode As Boolean, ParamArray Params() As String)
            If EditMode Then
    
                  'code'
    
            Else
    
                  'code'
    
            End If
        End Sub
    
    End Class
    i mean it works fine and i have various ways i do this but basically it works im just wandering how other people would approach this.
    Yes!!!
    Working from home is so much better than working in an office...
    Nothing can beat the combined stress of getting your work done on time whilst
    1. one toddler keeps pressing your AVR's power button
    2. one baby keeps crying for milk
    3. one child keeps running in and out of the house screaming and shouting
    4. one wife keeps nagging you to stop playing on the pc and do some real work.. house chores
    5. working at 1 O'clock in the morning because nobody is awake at that time
    6. being grossly underpaid for all your hard work


  2. #2
    .NUT jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    97,669

    Re: Input form basics

    I would tend to have a form that takes an object as input and lets the user edit that object. The object would be new for adding and existing for editing. The Load event handler would determine whether it was adding or editing and configure the form appropriately if required. That would generally be done based on the ID, which would be Nothing or zero for a new object. The dialogue would not be responsible for any data access. It would simply get the object and modify it. Where the object came from and went to would be none of its concern.
    Why is my data not saved to my database? | MSDN Data Walkthroughs
    VBForums Database Development FAQ
    My CodeBank Submissions: VB | C#
    My Blog: Data Among Multiple Forms (3 parts)
    Beginner Tutorials: VB | C# | SQL

  3. #3

    Thread Starter
    Fanatic Member
    Join Date
    Feb 2013
    Posts
    899

    Re: Input form basics

    i like that approach, i have not tried coding it that way before but its exactly how i would want to approach it, i think ill try that ........

    i dont like having forms controlling all the calls and although i make it work that way before (just to keep things simple) its not something i liked... im pretty sure too i could apply this method to too minimize the amount of forms im using in a project (for example i have several forms using the same controls and layout to perform different operations)

    but the bottom line here is? that your using the calling code to retrieve the data from the form and handle it in the calling code..?
    Yes!!!
    Working from home is so much better than working in an office...
    Nothing can beat the combined stress of getting your work done on time whilst
    1. one toddler keeps pressing your AVR's power button
    2. one baby keeps crying for milk
    3. one child keeps running in and out of the house screaming and shouting
    4. one wife keeps nagging you to stop playing on the pc and do some real work.. house chores
    5. working at 1 O'clock in the morning because nobody is awake at that time
    6. being grossly underpaid for all your hard work


  4. #4
    .NUT jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    97,669

    Re: Input form basics

    Quote Originally Posted by GBeats View Post
    but the bottom line here is? that your using the calling code to retrieve the data from the form and handle it in the calling code..?
    Let's say that Form1 is the main form and Form2 is the editing dialogue. Form1 would retrieve the data from the database and create the data object. It would then create Form2 and pass in the object. When Form2 closes, Form1 doesn't have to do anything to get the data. It still has a reference to the object it passed into Form2 and that object has been modified by Form2. Form1 then just saves those changes back to the database.
    Why is my data not saved to my database? | MSDN Data Walkthroughs
    VBForums Database Development FAQ
    My CodeBank Submissions: VB | C#
    My Blog: Data Among Multiple Forms (3 parts)
    Beginner Tutorials: VB | C# | SQL

  5. #5
    PowerPoster techgnome's Avatar
    Join Date
    May 2002
    Posts
    31,461

    Re: Input form basics

    I usually go a step further... I make the data object responsible for getting its data. Then Form1 doesn't care if the data comes from a database, excel file, or a text file.
    So the code behind an Add button might look like this:
    Code:
    Dim newPerson = new Person()
    Dim F2 as New Form2(newPerson)
    if F2.ShowDialog() = ShowDialogResult.OK Then
      newPerson.Save()
    End If
    The edit might look something like this:
    Code:
    Dim currPerson = new Person(1)
    Dim F2 as New Form2(currPerson)
    if F2.ShowDialog() = ShowDialogResult.OK Then
      currPerson.Save()
    End If
    Here I'm hard-coding an ID of 1 for the Person ID... but the idea is that I pass in the ID to the constructor, it goes out, finds the data and populates the Person class with the data for that person record with that ID and returns it. It's then passed to the form, where the user can edit it. Upon closing, if the user clicked OK, it's saved. Again, Form1 is ignorant of the actual data storage details.

    Now, I don't always follow this pattern, sometimes it doesn't make sense, sometimes this pattern can just get in the way, but when I can help it, this is what I prefer to do.

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  6. #6
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    31,562

    Re: Input form basics

    I have never thought I had a pattern, and still don't. I think I've done all the different patters described. It all depends on what feels right at the time, to me.
    My usual boring signature: Nothing

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Featured


Click Here to Expand Forum to Full Width