Limiting Found Set

[jgrunschel]

Hello,

Okay, here's the scenario:

You're in form view, and press a search button. A little search window pops up (a form). You type your criteria, and the search pop up window changes to show the results of your found set (a list).

I have all of this working beautifully. However, the search/results window changes height according to the number of found records. To avoid a ridiculously tall window, I have a cap set to limit the window height to the desktop height [Get ( WindowDesktopHeight )].

In the event of more than 10 found records, I'd like to be able to "page" through the results (like Google results). I've thought about using [Get ( RecordNumber )], [Get ( FoundCount )], the [Mod ()] function, and a global field holding the current "page" number to only show the records for each "page" (Page 1: Records 1-10; Page 2: Records 11-20; etc.). However, I'm at a total loss as to how to modify the find (Constrain/Extend Found Set) to show only the appropriate records.

I've also thought about using a self Join with a tab control and a portal on each tab with each portal starting row different. This limits the number of "pages" to whatever the number of tabs would be.

I've attached a picture with the "page" details hard-coded into the layout, just to convey my idea. Hopefully, everything I've said makes sense.

[comment]

To avoid a ridiculously tall window, I have a cap set to limit the window height to the desktop height

Is this necessary?

[jgrunschel]

Sorry, I went camping over the weekend and was without technology. Anyway.

Is this necessary?

With the way my script is currently written, yes.

I get the top, left, height, and width of the "results" window, then use the Move/Resize Window script command. Where the width is a fixed width to match my "results" layout and the height is based off of the FoundCount:

Let ( [ x = Get ( FoundCount ) ; h = 20 * x + 171 + ( Get ( WindowHeight ) - Get ( WindowContentHeight ) ) ] ;

    Case (

        h > Get ( WindowDesktopHeight ) ; Get ( WindowDesktopHeight ) - 4 ;

        h

    )

)

So, if the found count is huge, then the window's height will also be huge, which is why I included the Case statement.

However, I'm very new at this, so maybe I'm missing something.

[comment]

I don't think a window can be taller than the desktop, no matter what you specify in Move/Resize Window (perhaps that's not true in Windows?). If there are more records than what will fit in the window, the window will acquire a scroll bar - which IMHO is much more convenient than a page system.

[jgrunschel]

perhaps that's not true in Windows

You are correct. I don't know why Windows does it, but when you resize a window larger than the desktop, or move a window off of the desktop, the desktop grows scroll bars to accommodate. The two screen captures show this phenomenon.

The first picture (NoScrollBars.jpg) has the window height cap "on". While the second picture (ScrollBars.jpg) has it "off".

I was hoping to get some sort of "pages" results, mainly, because I thought it would be cool. However, it seems like it's not worth the effort.

Right now, the "View Selected", "Edit Search" and "Cancel" buttons are part of a trailing summary layout part, so they are tacked on after the results. So, I was thinking about putting the buttons in a footer part. That way, they are always visible no matter how many "results" are shown. Also, a footer would allow me to use a fixed window height.

[comment]

the desktop grows scroll bars to accommodate.

Perhaps I am misinterpreting what I see (not being a Windows user), but it looks like the scroll bar is attached to the window, not to the desktop.

In any case, you could easily limit the window height to something like:

Min (

Get (FoundCount) * recordHeight + margins ;

Get (WindowDesktopHeight) - Get (WindowTop)

)

This way the window will never extend beyond the desktop's bottom boundary, and you'll get a scroll bar if there are more records hidden from the view. And yes, the buttons should go inside the footer (or the header) part.

[Vaughan]

Remember that under WindOS, the FileMaker windows are contained within the application window.

My guess is that the FileMaker application window is showing the scroll bars.

[jgrunschel]

I feel like we've gone a little off topic, because I don't have any problems with limiting the size of the window. That all works fine.

Remember that under WindOS, the FileMaker windows are contained within the application window.

By the way, it is the application window that has the scroll bars.

I was just wondering if it were possible to have a layout that shows x number of results per "page". Anyway, thanks for the info.

Edited May 19, 2009 by Guest

[comment]

I was just wondering if it were possible to have a layout that shows x number of results per "page".

Of course it's possible - it's just not exactly simple, and IMHO not the best user interface. There's some justification for it when you get thousands of results, like you will in Google - but it could be said that a poorly focused find is the real problem, and the paging merely a necessary evil as a result.

Anyway, if you want to do this, you'll need to store a list of the "real" found set ID's in a global field or a variable, and use appropriate sections of it to create reduced found sets for the user. You can see a very similar method applied to a portal here:

http://fmforums.com/forum/showpost.php?post/201804/

[jgrunschel]

I can see how it wouldn't be the best solution, but I think this is the solution that I'm looking for. Who knows, as the project develops, things often change according to beta testing feedback and such.

Thanks for the point in the direction I was looking for!