How to combine three methods into one?

Simflex 131 Reputation points

Greetings mates,

I have three methods:

  1. A search method has control ID of btnSearch that searches the database. If record exists, load the form with the records. If no record exists, present a blank form for inserting records. This works perfectly.
  2. The second method called btnPreview which I get help with here, allows user to preview the records whether this is a new record or existing record before submitting to the DB. Again this works very well.
  3. The third method called btnSave is intended to be used to submit all the previdwed records into the database.

My doubt is how to I integrate all three methods and get them to go from search method to preview method to submit method. Can all three be combined into just one, if yes, how?

I don't believe I need coding assistance here; just how to approach this.

Just to add to the three bulleted items above, in the preview method, I have another sub called fillSummary().

Private Sub FillSummary()
  lblNumbersUpgraded.Text = ddlNumber.SelectedValue
  'rest of the form fields
End Sub

This is where the form fields data are previewed for accuracy.

Then on btnPreview() method,

Protected Sub btnPreview_Click(sender As Object, e As EventArgs)


End Sub

Many thanks in advance.

An object-oriented programming language developed by Microsoft that is implemented on the .NET Framework. Previously known as Visual Basic .NET.
1,971 questions
An object-oriented and type-safe programming language that has its roots in the C family of languages and includes support for component-oriented programming.
7,562 questions
A set of technologies in the .NET Framework for building web applications and XML web services.
1,322 questions
{count} votes

1 answer

Sort by: Most helpful
  1. Albert Kallal 3,451 Reputation points

    Ok, I actually think that "one" UI is fine here. But there is a bit of confusing:

    if record exists, load the form with the records.

    Hum, above is not clear. You search for some record, and say pick the one you want. You then display that record for editing. But "then" you use the term "records" ????

    so, it not clear how we gone from a record to now the term records???

    Perhaps this is a type of invoice, where we have say a parent record (the invoice information), and then say some child rows of data that makes up the details of that invoice?

    But this "context" flip in your narrative from I find or display a record, and then go on to say you THEN display records? Don't you mean you display the one record? (so, it not clear how we gone from "a Record" to now "records"? That's just not clear.

    And I think where things are falling apart here?

    You say you search for a record, and if not found, then show a blank record for editing. That is VERY rare of a UI. since what happens if I miss search, then why would I display a blank record for editing when I really just want to search again?

    it seems to me, that just about "every" system I ever used has some type of search, then display results.

    However, if no results, then user can search some more until they find what they are looking for. However, say they don't find, or can't find? Then you have users just hit a handy dandy add button.

    The result?

    Both the "view to edit" and the "add to edit" will result in BOTH cases me winding up on the SAME page to edit that information (either blank or new). As a result, the UI is 100% consistent here, but more important the code behind to edit that "existing" record can and will thus display the SAME ui choices.


      Save,   cancel (go back),   Delete

    So, now, the operations are combined, but only difference is we don't out of the blue toss the user into some blank edit for JUST because their search failed.

    So, the classic edition loop (for just about EVERY system from accounting to whatever system I have ever used) is thus:

               search for something
              display results of search - let user pick one to edit
                   ----> edit form with above 3 buttons.
        do until end of work day

    of course, in above, we also have a "add" button. The add button will simple jump to that edit page, and thus again allow the SAME ui to edit the one record, and the save button in effect is really a "add new record + save". But, the users tend not to think that way.

    Give this sample link a try. It is ONE page to edit some sample data:

    I used a pop up to edit, but there is no reason why I could not just say "hide" the grid" when editing, and re-show the grid when the user exits out of the editing.

    So, in the above example, note how the SAME code and more important the SAME UI exists for a add new record, and that of a edit existing. I don't have 2 sets of code here. The same code used to save a record is used in both cases. (it checks for a database PK id, and if "0", then I add this record as new.

    so, I still might not be grasping your issue, but give the above edit a record example, it might give you some ideas.