Contact details window in ms access?

I'm currently using the MS Access 2010 template for contacts. I've modified it to do a multiple criteria search, but it's still the same. What I'd like to know is how to modify the contact details window that opens when you click "open".

Basically, I want it to open the window, but then I want to add two buttons to go to the next person without having to close the window and reopen another one. I开发者_C百科've added the buttons, but the window opened is for a specific ID, so it won't go to the next record.

Does anybody know how to open the contact details window for a specific contact but still be able to go through all of them? (them being the contacts given after the search)

EDIT:

Ok, i've just tried to create a clone, but all i get is a error "3251 - this operation is not supported for this type of object. I'm relatively new to VBA code, so its kind of hard to find the issues, but i'm guessing it has something to do with type of recordset (DAO or ADO). Here is what i have:

Private Sub txtOpen_Click()

DoCmd.OpenForm "Contact Details", , , , , acHidden
  With Forms![Contact Details]
    .Recordset = Me.Recordset.Clone
    .RecordsetClone.FindFirst "[ID]=" & Me!ID
    If Not .NoMatch Then
       .Bookmark = .RecordsetClone.Bookmark
    End If
  End With

End Sub

I'm currently looking into it though!

I haven't checked the A2010 contacts template, but my guess is that you have a list of results and you select one and click a command button to open the details.

Likely that command button has code something like this:

  DoCmd.OpenForm "frmContactDetails", , , "[ContactID]=" & Me!ContactID

...which opens the form and filters it to a single record.

To have a navigable set of records, you'll instead want the form to be filtered to the same set of records as is displayed in the list of search results, and then you'll want to navigate among those. To do that, you'd have to set the criteria to the same criteria that filtered the results list, and then navigate to the currently selected record. I don't know what the criteria are, so I'm just going to represent it with a variable, strCriteria but the requirement is that it be formatted like a SQL WHERE clause without the word "WHERE":

  DoCmd.OpenForm "frmContactDetails", , , strCriteria
  With Forms!frmContactDetails
    .RecordsetClone.FindFirst "[ContactID]=" & Me!ContactID
    If Not .NoMatch Then
       .Bookmark = .RecordsetClone.Bookmark
    End If
  End WIth

This opens the form to the same set of records, then navigates to the one with the ContactID of the record that was selected in the results when you clicked the command button to see the details. Once that detail form is loaded with that set of records, you can navigate to the next or previous records as you like.

It may also be possible to open the detail form and assign the form's Recordset to be a clone of the results form's Recordset, but I've never tried that. In that case, it would be something like (untested code, just guessing at how this would be done):

  DoCmd.OpenForm "frmContactDetails", , , , , acHidden 
  With Forms!frmContactDetails
    .Recordset = Me.Recordset.Clone
    .RecordsetClone.FindFirst "[ContactID]=" & Me!ContactID
    If Not .NoMatch Then
       .Bookmark = .RecordsetClone.Bookmark
    End If
  End WIth

Another thing to consider is not having a popup form at all, but use a split form, something that was introduced in A2007, and that I've not had the opportunity to use yet (no clients who've switched fully to A2007/2010). It has a list view and a detail view on the same form.

The old-fashioned way to implement the same thing was to have two subforms on an unbound form, the top form being the list of results, and the top form being a detail form that is tied to the current record of the top form. No code is required, you just set the LinkChild and LinkMaster properties of the detail form like this:

  LinkMaster: ListForm.Form!ContactID
  LinkChild:  ContactID

This approach and the split form both avoid the popup form, which I consider somewhat user-hostile (it needs to be used sparingly).

Which approach you use depends on exactly how you app fits together.