You can use the classic "page at a time" logic with instance lists, but an over-reliance on it may indicate that your filters have not been designed properly.
The purpose of a filter is to give the end-user sufficient search power to rapidly produce short instance lists of exactly what they want to work with. If your end-users must always have to page to find the information they want to work with you should consider increasing the "zoom in" capability of your filters before attempting to implement complex paging techniques. Users do not want to scroll though pages and pages to find what they want.
For example, if you are designing a Human Resources system, one of the essential pieces of analysis you need to do is to work out all the different ways that end-users would want to build list of employees. For example:
If you have a system with 5000 employees then simply blasting the personal file out onto the screen with some page at a time logic will not make the end-users life any easier.
Sometimes Framework designers take this one step further and let end-users define (and store) standard employee 'queries' that they can use over and over in filters to build instance lists.
For example, a HR person tasked to ensure employee satisfaction, may, on every Monday morning, need to build a list of all the people who started work last week.
Equally another may need to build a list every Friday afternoon of people working at a certain remote location so as to phone them up to see if they have any special transportation requirements needed on the weekend.
Think about giving end-users the EXACT list of what they need rather than a large list with some accompanying "page at a time" scrolling logic.