Search within a form 4

[Phil Thoms]

Hi, As most of you will realise with recent queries I am migrating to VFP6 from FP 2.6.
I want to use a textbox in a form to search for a record in a large database, once the record is found I wish to browse the result in a larger form. What is best way of achieving this. This would quite simple in the old FoxPro but not sure where code goes in VFP.
Thanks.

 

[Mike Lewis]

Philthoms,

I suspect you alreay know the answer to this:

1. Create a form in the form designer.

2. Add a text box and a button to it. Label the button "Search".

3. In the Click event of the button, write whatever code is appropriate for searching the table, based on the value of the text box.

For example, if the text box is named Text1, and you want the user to enter the customer ID in the text box, your code might look something like this:

lcValue = ALLTRIM(UPPER(THISFORM.Text1.Value))
SELECT MyTable
LOCATE FOR ALLTRIM(UPPER(Cust_ID)) = lcValue
IF NOT FOUND()
  MESSAGEBOX("No such customer")
ELSE
  * do something with the customer
ENDIF

You are now sitting on the required record within the table, and you can display it in any way you like.

You said you want to "browse" it in a larger form. The VFP equivalent of a browse window is grid, but I suspect that's not what you meant, as you wouldn't normally browse a single record.

Perhaps you could try the above, and then let us know what you want to do next.

Mike






__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[JRB-Bldr]

To do an actual BROWSE of ALL records matching your input criteria, I do things very similar to what Mike has suggested above.

I have a secondary Form (e.g. ViewResults) to display the results.
In that form I have a Grid which has a RecordSourceType = Alias and uses a 'generic' data cursor/table as its RecordSource (e.g. ResultData).

In my primary Form I have a Textbox to accept the user input.

When the user enters the value and clicks on Search I do something like the following in the Search Button's Click Method:

cName = ThisForm.txtName.Text   && Get input string
nLenName = LEN(ALLTRIM(cName))  && How long is string

IF !USED('SrchTable')
   USE SrchTable IN 0
ENDIF

* --- Find ALL Records where LEFT n characters of SrchTable Name exactly matches the Input string ---
SELECT *;
   FROM SrchTable;
   WHERE LEFT(ALLTRIM(SrchTable.Name),nLenName) == ALLTRIM(cName);
   INTO CURSOR ResultData READWRITE

SELECT ResultData
IF RECCOUNT() > 0
   * --- Temporarily Hide This Form ---
   ThisForm.Hide
   * --- Display Resultant Data In View Form ---
   DO FORM ViewResults
   * --- Re-Display This Form ---
   ThisForm.Show
ELSE
   WAIT WINDOW "No Results Found!" TIMEOUT 4
ENDIF
IF USED('ResultData')
   SELECT ResultData
   USE
ENDIF

Note what you do in the secondary Form is up to you - just View the results or do something more.

NOTE - If you want to do something more, you might want to consider just displaying the Found record values in individual TextBoxes on the main form and not use a secondary form at all.

Good Luck,
JRB-Bldr

 

[Phil Thoms]

Thanks for your help. What you have suggested works well.
Just one question:- when I have come across similar search boxes on the internet you don't have to use the search button at the side of the textbox, just pressing 'enter' activates the search as well as pushing the button.
Regards.

 

[Olaf Doschke]

You can program whatever you want. Who hinders you to not use a seperate button and react in the Lostfocus() event to do the search there. Lostfocus can be triggered by RETURN key, but also with a TAB and the downside is, any mouseclick somewhere else on any other control will trigger a search. In case of a more complex search form with a bunch of input textboxes this is not a good idea.

The better way is to have a search button. You can set it's property "DEfault" to .T., which means it's the (one) button on the form to also react to ENTER. And then you can put this button below the visible area, if you really don't want it in your user interface, but it would still work in case of ENTER being pressed.

Bye, Olaf.

 

[Mike Lewis]

Philthoms,

Keep in mind that if you fix it so that the user can hit Enter to start the search, that particular textbox will behave differently from all the other textboxes in your application.

That might not matter, but in general it's best for controls to behave in a consistent way.

If you definitely want to do this, the following code will get you started:

* This is the keypress event of the textbox

LPARAMETERS nKeyCode, nShiftAltCtrl

IF nKeyCode = 13
  * 13 is the code for Enter

  * Do the search here

  NODEFAULT 

ENDIF

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

Mike, this seems an overlap. I'd strongly recommend using the .Default property of buttons, it's meant for that case. No need to modify the keypress of a textbox also. Just SET CONFIRM ON, the textbox will lose focus on ENTER too.

Bye, Olaf.

 

[Mike Lewis]

Olaf,

I don't disagree. The only (minor) objection I have to using the Default property is that there might need to be more than one Default button on a form. But I agree that would be easy enough to work around.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Phil Thoms]

Thanks for your comments, I think the search button alone is the best way to trigger the code. Just one more question:- if you wish to show the result of a computation on a form, ie a total on a certain value field within a client database, would you use the @say command or the ? command or is there another better way.
Once again thanks for your assistance.

 

[Phil Thoms]

A previous question was where to purchase VFP 9.
I am in the UK and I have seen it advertised on eBay.
Thanks

 

[Mike Lewis]

You might try Grey Matter, or QBS. I haven't checked to see if either of them have it, but it's exactly the sort of product they would sell, so worth a try.

You should be able to find them via a web search.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Phil Thoms]

Thanks Mike.
Just one more question:- if you wish to show the result of a computation on a form, ie a total on a certain numeric field within a client database, would you use the @say command or the ? command or is there another better way.Once again thanks for your assistance.

 

[Mike Lewis]

Philthoms, for the reasons we discussed in thread184-1632496, you wouldn't use @/SAY, or the ? command.

Instead, place a label on the form. To make the label display the result of a computation, set its Caption property to the data in question.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

I'd use a textbox, perhaps set readonly, to display such a calculation result.

It's really up to the overal design of the form what fits best. But typically I use labels only for captions of controls to give them a caption, what they're showing and have values in textboxes or other controls.

Think about how other windows applications do it.

Bye, Olaf.

 

[Phil Thoms]

Thanks for all your help. I have now created a search form which is working well. Just one more query:-
You can activate a window inside another window, is this possible with forms or is this type of action never required ?
Many thanks.

 

[Mike Lewis]

Yes, it's quite usual for one form to launch (or activate) another.

In a typical case, the first form will show some sort of overview of certain data: perhaps a grid showing records found in a search. The user might then select a record within the form, and then perform some action - such as clicking a button - to launch a subsidiary form. The subsidiary form will then show the details of the selected record.

To achieve that, the first form simply executes a DO FORM command. It can also pass parameters to the subsidiary form. In the above scenario, it would pass the record number or primary key of the selected record.

To understand this properly, you really need to know the difference between modal forms and modeless forms. That's too much to explain just now. You really need to read up on this in the help file.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Phil Thoms]

Thanks Mike, I'll take one step at a time.
I keep saying just one more question, however how do you validate user entry on a text field if say the choices are 1,2,3 and 9 would it be $'1239' as per the old @say/get commands, ie get field valid field$'1239' ?
Thanks once again.

 

[Mike Lewis]

This is easy. You write code in the textbox's Valid event. The code will fire when the user tries to leave the textbox.

The code should return .T. if the validation succeeds, .F. if you want to keep focus in the textbox so that the user is forced to make a correction.

In this case, the code in the Valid event would look something like this:

IF this.Value $ "1239"
  RETURN .T.
ELSE
  RETURN .F.
ENDIF

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Phil Thoms]

Thanks Mike, my form is behaving well.
Is it possible to open a browse within a form without using the grid ?
Thanks again.

 

[Mike Lewis]

Yes, you can execute a BROWSE command, exactly like in Foxpro 2.6. But the Browse will open in its own window.

A grid is generally considered a better approach. A grid is easier to control than a browse window, it can be properly integrated in a form, and it can respond to events.

In particular, you can do things like launching a subsidiary form when the user double-clicks on a record within a grid.

Use a Browse window if you just want a quick-and-dirty way of displaying the data, but for most applications, you should use a grid.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy