Search Form

[ChrisAgius]

Anyone have a clue where I can find a form or component in Foxpro where I can pass Tables and Cursors to this form and I can search on different orders.....

I am developing this type of component but I am finding some problems with the Keypress Event. I need that when I press a key the seek command will search the value of the search textbox in the table but ... the textbox has to loose its focus to recrod the key I pressed in its Value...
Any Idea

Thanks

 

[StewartUK]

Chris,

Um, As far as I'm aware, the text box doesn't have to lose focus, the keypress event should be able to do the search.

I've had problems in this area as well and found an article in FoxTalk quite useful. You might want to look at it, it is at

http://msdn.microsoft.com/library/default.asp?URL=/library/periodic/period99/FT99L15.HTM.

I hope I got it right!

Hope that helps a bit,

Stewart

 

[TomasDill]

Chris, you can use InteractiveChange event of text box that is much better, because in the Value property you wil have already processed value. Processed means that such keys as backspace, del, cut functionality etc will be already processed and InteractiveChange after that called. This way is more reliable, I guess.

Vlad Grynchyshyn
vgryn@softserve.lviv.ua

http://www.softserve.lviv.ua

The professional level of programmer could be determined by level of stupidity of his/her bugs

 

[ramani]

I have a form doing the similar function with incremental search provision. I have not used any other event except the interactive change event of the text box.
***********************************************************
SEEK (ThisForm.cKeyPreFix + ALLT(This.Value))
This.Parent.Setme() && the function which sets focus to the grid and then sets focus to the text so that the grids current row shows selected. (Probably this is the problem you face).
***********************************************************
Note the cKeyPreFix is useful, if the form search includes an invisible prefix to the key and so remains already filtered. I included this as this could through some light in your generic coding. In fact you can even think of providing for wildcard * searches which I have implemented.

Hope this is of some help to you.

ramani
FoxAcc
ramani_g @ yahoo.com

 

[weedz]

In response to ramani's reply,

ISO a SEEK it is nicer to use a LOCATE. In this case you do not have to set an index.

Every time my user types an extra character, the locate is issued again and the nearest match is found (if it exists), otherwise, the record pointer is not moved and stay's on the last record found.

LOCATE FOR myTable.Field <= MyvalueToSeek

HTH,

Weedz (Wietze Veld)

http://www.crowncap.demon.nl

veld4663@exact.nl

They cling emotionally to code and fix development rather than choosing practices based on analytical assesments of what works best.

After the GoldRush - Steve McConnell

 

[fluteplr]

At the risk of violating the no selling policy. Since you asked. Look at QBF Builder. It is a drop on Query By Form builder component.

http://www.classyconsulting.com

 

[fluteplr]

Sorry wrong url.

http://www.classycomponents.com.

My fingers got into autotype mode.

 

[ramani]

SEEK can be used if that field is the current index. Otherwise LOCATE can be used.
SEEK will be very very fast compared to LOCATE

ramani

 

[fluteplr]

Actually the difference between a seek and a locate can be quite small assuming there is an index the locate statement can use. (and you don't have any non optimized filters set).

 

[weedz]

Concerning the locate and seek, what would you do if you wanted to transfer your database system from VFP to f.i. SQL server ?

LOCATE is a SQL statement, SEEK is not. Then you would have to replace all your seeks with LOCATE.



Weedz (Wietze Veld)

http://www.crowncap.demon.nl

veld4663@exact.nl

They cling emotionally to code and fix development rather than choosing practices based on analytical assesments of what works best.

After the GoldRush - Steve McConnell