Find Button Code

[Guest]

Please can someone help...........!!!!!!!!!!!!!

i'm trying to finish my database and i'm having one little problem.

I want to program the find record button so that it looks in the parent form
(whole form) and is set to any part of field

so far i have this in the code of the button generated by the wizard

DoCmd.DoMenuItem acFormBar, acRecordsMenu, 5, , acMenuVer70

 

[Allen Browne]

Set focus to the parent form:
Me.Parent.SetFocus

Then set focus to something in that form that is not a bound control, such
as a command button:
Me.Parent.cmdMyButton.SetFocus

Then activate the Find button:
RunCommand acCmdFind

 

[Guest]

thank you so now the code looks like this


Me.Parent.Command147.SetFocus
RunCommand acCmdFind
DoCmd.DoMenuItem acFormBar, acEditMenu, 10, , acMenuVer70

But i am always getting a message - the expression you entered has an
invalid reference to the parent property

what should i do now!
please help

 

[Allen Browne]

Is this code in a subform? The parent property applies only to forms that
are open as a subform.

If the form is not a subform, just setfocus to a command button on the form,
and then find, e.g.:
Me.Command147.SetFocus
RunCommand acCmdFind

 

[Guest]

Thats great! But now for the last part i want it to be set that automatically
set to look in any part of field not in whole field. I saw you recomeneded to
another query to use tools options Edit/find find replace behaviour and put
it on general search. I tried this and saved the form went back into it but
nothing doing its still defaulted to Whole field. Am i doing something wrong
or is there another way of doing this?

 

[Allen Browne]

If you can't get the SetOption to work, you could use:
SendKeys "%HA", False
RunCommand acCmdFind

 

[Guest]

Thanks so much that did it!!!! have a great day!

If you can't get the SetOption to work, you could use:
SendKeys "%HA", False
RunCommand acCmdFind

 

[Demi]

Allen, MSDN warns do not use send keys as menus in versions change, so
i'm wondering are there dropdown methods of the Find Dialog box, or
anyother way?

OK, yes this worked for this question, but why are there two find
commands? Above I see both...
RunCommand acCmdFind
and DoCmd.DoMenuItem acFormBar, acEditMenu, 10, , acMenuVer70

both of these were in the same code sample.
Also why are the sendkeys sent before the find command? Just curious
how it works.

Code snippet...

Screen.PreviousControl.SetFocus
SendKeys "%HA", False ' Search Anywhere in the Field
SendKeys "%LD", False ' Search the whole Table in my test Example
only
RunCommand acCmdFind ' Opens the Find dialog box. Available in
both VBE and non-VBE views.
DoCmd.DoMenuItem acFormBar, acEditMenu, 10, , acMenuVer70 ' not
sure why there are two find commands? old style? dh

 

[Allen Browne]

Yes, Demi, Sendkeys is always a last resort.

Stuffing keystrokes into the keyboard buffer is a crude, brute-force
approach. The keystrokes go to the active window, whichever that is. In a
multi-tasking environment, you don't know that the window you expect will
have focus when the program runs, and who knows what it might do if some
other window gets focus.

There is a bug in Access, where SendKeys messes up the state of NumLock as
well.

In early versions of Access, Microsoft introduced DoMenuItem as a way to
programmatically initiate an item from a menu. The arguments are zero-based,
so acEditMenu has the value 1 (the 2nd menu), and 10 represents the 11th
item on the menu. But the menu items changed in the different versions of
Access, and people customized their menus. As a result, MS standardized this
to the menu bar items that were present in Access 95 (i.e. version 7.0.) So:
DoCmd.DoMenuItem acFormBar, acEditMenu, 10, , acMenuVer70
actually means:
Activate the 11th item from the Edit menu of the Form menubar,
whatever that was on the original Access 95 menu structure.

If that sounds arcane to you, I guess it did to Microsoft as well, so, in
Access 97, they introduced RunCommand as a safer and more reabable way of
getting at the menu items (and a bunch of other things too.) RunCommand is
therefore the preferred approach. There are even cases where RunCommand
works while DoMenuItem does not (e.g. some actions in popup forms, where the
Access menus themselves are not available.)

However, Microsoft never got around to re-writting all the wizard code that
used DoMenuItem. To this day, the wizards are still creating arcane code.
That's a real shame, because many users learn to code by seeing what the
wizards do, even though the wizard code is sometimes the worse possible
choice. And they made it difficult for people to learn to use RunCommand,
because there is no real list explaining what the 500+ constants actually
to. To my knowledge, the best list is this old one from Terry Wickenden:
http://www.tkwickenden.clara.net/

 

[Guest]

I'm having a little problem. I'm at work now and i tried out this code here
and it worked

Me.Command147.SetFocus
SendKeys "%HA", False
RunCommand acCmdFind

I go home and try it on the database at home that i really need the code for
and it tells me something about a non-searchable control! I did exactly the
same thing - what could be my problem.

Also i saw you wrote that the sendkeys is a last resort thing but in my case
will it give me any problems?

thanks for all your help!

 

[Allen Browne]

Sorry: I do not know why you are able to get the code to work on one
computer and not on another.

Setting the options would be preferable to SendKeys, but you were not able
to get that working either.

 

[Guest]

Hi i'm still having one little problem with this find button. It all works
fine but when i press my find button then the focus on the find menu bar is
on 'any part of field' because i set it to that with the sendkeys but i cant
automatically type and press enter to find someone i have to click the cursor
into th find what bar of the little find menu and then type what i am
searching for.

Is there any way that i can set it like a normal find button that it will
automatically let me type?

thanks a milion for all your help!!