Weather Girl,
If you've got a handle on using tilde variables, then all you really need to worry about is assigning the values into those variables. Mac's comment about doing it directly from the form is well-taken, for you avoid the overhead and hassle of dealing with your criteria table.
Here's an example taken from something I did a while back that shows a few different things:
Code:
method pushButton(var eventInfo Event)
; ----------------------------------------------------
; This routine verifies that the user has selected a
; department and runs the query this form automates.
; ----------------------------------------------------
var
loRetval Logical ; Flag - success or failure.
strValue String ; Holds user's selected department
qryPrint Query ; Query using user's selection.
tcAnswer TCursor ; Results, for performance and eval.
endVar
const
ERRTITLE = "Can't Print Roster" ; title of error dialogs.
endConst
setMouseShape( mouseWait )
doDefault
; First, initialize the flag variables.
loRetval = TRUE ; Assume we'll succeed.
strValue = fldDeptList.value
If strValue.match( "<..>" ) then
strValue = ".."
endIf
; Now, define the query and try to run it.
qryPrint = Query
:DATA:EMPLOYEE | Department |
Check | ~strValue |
endQuery
Message( "Selecting employees..." )
If not qryPrint.executeQBE( tcAnswer ) then
; The query could not be run, display the error
; and save the query in :PRIV: for debugging.
errorShow( ERRTITLE,
"Reason: The query failed to run; " +
"see details..." )
qryPrint.writeQBE( ":PRIV:BADQUERY.TXT" )
loRetval = FALSE
else
; The query ran, so see if we got any records.
If tcAnswer.nRecords() = 0 then ; no matches
setMouseShape( mouseArrow )
msgStop( ERRTITLE,
"No matches were found for your " +
"conditions. Please try different " +
"ones." )
loRetval = FALSE
else
; create the ANSWER table
tcAnswer.instantiateView( ":PRIV:ANSWER.DB" )
endIf
endIf
; Save the user's criteria to an environment
; variable so it appears on the report.
writeEnvironmentString( "RPTTITLE", fldDeptList.Value )
; Make sure the TCursor gets closed
If tcAnswer.isAssigned() then
tcAnswer.close()
endIf
; If the process succeeded, then close the form.
; Otherwise, stick around so the user can try again.
setMouseShape( mouseArrow )
if loRetval then
formReturn( True )
endIf
endMethod
In this case, the form contained a listbox containing a list of the departments in the lookup table and an extra item as the default ("<All Departments>"
. Near the beginning of the code, we see if the listbox is set to the all departments value and, if so, put a wildercard into the variable (though it probably should have been blank) or we put the value selected by the user.
Next, we defined the query and included the user's selection using a traditional tilde variable. (Note the shortcut for automatically checking all fields.)
Now, we try to run the query, using a variation that stores the results in memory, rather than an ANSWER table. This is a significant performance benefit, though you'll note that we still pay that price by actually creating the ANSWER table later.
However, before we do, we check to see if there were any matches to the underlying query. (Perhaps the department called HLSEC hasn't actually hired anyone yet.) If no matches are found, we display a note to the user and let them try again.
Note, though, that there's some code to make certain that the query ran. If there's a problem, you'll notice we do two things: 1) We save the query to a separate .TXT file so it can be reviewed for problems and 2) display the contents of the error stack to the user, so they get an idea of what Paradox thinks the problem is.
Depending on the experience of your users, you may need to override that, but it's a good place to start.
Next, you'll notice that we write the actual criteria value to an environment variable. This is done for the sake of the actual report, which contains a calculated field to read the environment variable and update the the report's page header accordingly. (That way, you'll be able to tell one report from others accidentally left on the top of the laser printer.
At this point, we do the standard clean-up process, which should always include a formal closing of your TCursors. While it's not as bad of a problem in recent versions of Paradox, older ones would periodically leave TCursors in memory, even after the variables pointing to them were no longer in scope. Thus, you'd get memory leaks and odd-little "Record Already Locked" errors. So this is a good safety strategy to use.
Finally, you'll note that we do not automatically do a formReturn( TRUE ) unless the query is successfully run. That way, the user can modify the query conditions until they actually get results from their efforts.
There are certainly many different ways to do this, but I hope it helps a little...
-- Lance
RIV:ANWSER
B"