That is what I typically do. Many forms will have a grid for browsing and a data entry section on the same form, or the main form will only have the fields for displaying editing and the toolbar. When you click search you enter the values you wish to search on and then a separate form with a "result" grid on it pops up with the result. You select the record you wish to view on the main form and the browseable grid form goes away. However, that same result set is used in the main form so you can step through the records using the toolbar. The nice thing about that is you can use the same result grid form from any form that calls it - you just pass the result set to it or you pass the query and dynamically display the columns.


>One option is to create a toolbar with those buttons in it (new, edit, delete, print..etc).
>
>>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).