GoTo Record

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have a form that has several linked subforms in it. It all keys off of a query that list Users Login ID, First Name, and Last Name. The Login ID is the primary key. I set up buttons to go to next and previous records. I am trying to set up one so that users can select a name from a combo box to go to a record. I have a second form with a combo box on it. It activates based on this search button. It lists users by name in the combo box and outputs their Login ID to a text box.

The problem it then how do I shift focus back to the origional form and goto the record for this Login ID that is in the text box ? I am not sure how to do this operation.

Does anybody have any insight into this. There may also be an easier way but this is what I have come up with so far. I am looking for any assistance or suggestions

Thank you

Adam Jones
 
Adam,

It seems that the process you are using here is unnecessarily
complicated. This is really just a style consideration, I guess, but
instead of a command button that opens a separate form with the
selection combobox, I would just put the combobox right on the main
form. In such a case, I typically use a different backcolor for the
combobox, and position it appropriately (e.g. "bundled" with the 'next'
and 'previous' buttons), to help make it clear to users that this is not
a data control.

And there seems to be no reason to "output their Login ID to a text
box". You can have your combobx set up with 2 columns, with the Login
ID as the Bound Column, but use the Column Widths property so that the
users name is what is shown. Then you can refer directly to the
combobox for the value of the Login ID.

If you do it like this, then you can use code similar to the following,
on the After Update event of the combobox (let's assume the combobox is
called FindPerson...
Me.Login_ID.SetFocus
DoCmd.FindRecord Me.FindPerson
Me.FindPerson = Null
 
that is slick, and so easy. it seems like the combobox wizard should use
this method when it builds the code to "find a record in the form", instead
of the recordset clone/bookmark code. i read the Help topics on FindRecord,
and didn't see any reason to *not* use it instead of recordsetclone.
is there any reason you know of, that i'm missing? i've used
recordsetclone/bookmark in the past - but your solution would be so much
easier...
 
Tina,

I know of no inherent problems with the FindRecord method.

Other suggestions we could have made to Adam would include...
Me.Filter = "[Login ID]=" & Me.FindPerson
Me.FilterOn = True

.... or...
Me.RecordSource = "SELECT * FROM MyQuery WHERE [Login ID]=" &
Me.FindPerson
(which may be a better option if the record set is very large)

I would prefer all 3 of these approaches to anything involving
recordsets and bookmarks.
 
so, FindRecord is a valid alternate to recordsetclone/bookmark. i have used
the Filter option. i've never changed the RecordSource at runtime though,
i'll have to keep that in mind, too. way cool - not one, but two new options
for me to work with. i don't know what Adam's view is on all this, but you
sure made my day - thanks, Steve! :)


Steve Schapel said:
Tina,

I know of no inherent problems with the FindRecord method.

Other suggestions we could have made to Adam would include...
Me.Filter = "[Login ID]=" & Me.FindPerson
Me.FilterOn = True

... or...
Me.RecordSource = "SELECT * FROM MyQuery WHERE [Login ID]=" &
Me.FindPerson
(which may be a better option if the record set is very large)

I would prefer all 3 of these approaches to anything involving
recordsets and bookmarks.

--
Steve Schapel, Microsoft Access MVP
that is slick, and so easy. it seems like the combobox wizard should use
this method when it builds the code to "find a record in the form", instead
of the recordset clone/bookmark code. i read the Help topics on FindRecord,
and didn't see any reason to *not* use it instead of recordsetclone.
is there any reason you know of, that i'm missing? i've used
recordsetclone/bookmark in the past - but your solution would be so much
easier...
Click to expand...
Click to expand...
 
i've never changed the RecordSource at runtime though,
i'll have to keep that in mind, too. way cool
Click to expand...

My favourite method is to use the Form_Open event to:-

a) launch a modal Search form that takes user requirements and returns the
identifier for either an existing record or a new empty one;

b) resets the form recordset to just that one record;

c) or aborts the Load if the user clicked Cancel.

The "OK" command button on the form also hides the form, then calls the
Form_Load procedure for another record, then either unloads the form or
unhides it pointing at the new record.


Just a thought...


Tim F
 
more and more goodies, thanks Tim! :)
though it'll take me some thought to get a clear picture of this one - heavy
barbell, weak biceps. <g>
 
Back
Top