I'm not really sure what you are asking, but I would add a previous, next, etc when there are records (to step through) as well...


>It could be on the same form. You don't have to prompt when the form loads but rather display the form with none of the fields enabled but with the buttons enabled: Search and New. Then only enable the Delete (save button when adding a new invoice) and the Print buttons when you are on a record.
>
>TC,
>
>I guess the "orientation of the data" must like the Edit mode of VFP's browse? If so, one then has to record navigation as well?
>
>Dennis
>
>>
>>>Naomi,
>>>
>>>So, everytime a user goes to say Invoices, he will be prompted with a dialog box asking for filter conditions. When user clicks OK, app will query first for number of records that satisfy the user-specified condition. It will then proceed to show them in a grid in batches of N records.
>>>
>>>At which part (or form) do you say we put the New, Edit, Delete, Print buttons?
>>>
>>>Thanks
>>>Dennis
>>>
>>>
>>>>>John,
>>>>>
>>>>>Use a search form to limit options or use demand paging on the grid.
>>>>>
>>>>>Forgive my ignorance, but what is demand paging? =(
>>>>>
>>>>>When you say search form, say when a user clicks on Invoices, an 'empty form' shows up right away asking for search details? If so, then another form fires up to show the results? Where must one put the New, Edit, Save, Undo functionalities?
>>>>>
>>>>>Thanks
>>>>>Dennis
>>>>
>>>>What I think John means, that the very first form must be a form that you enter some criteria (say, period of the invoices, or Customer(s) for invoices, or the like). Then the next step will be to get count of the invoices matching the criteria. If the count is too big, you can display a warning message to the user and show only top N (say, 200) records in a grid to view with buttons next /previous (or page numbers). And retrieve records for each page when the user clicks on that button. That's a typical paging interface (very common in Web, slightly less common in Desktop).