Hi Everyone,

After reading some white papers and talking to other developers many people seem to be in agreement that supressing the Status Area is a good idea when developing solutions for distribution to people other than other FMP developers.

I have programmed my most recent project that way and aside from some other things I really like the way it reclaims some valuable screen real estate.

However, I find it confusing when "finds" are performed that result in multiple records being located. Does anyone have a suggestion for best method in displaying "found count" that will not be confusing to my users who might be wondering why the number of records keeps changing on them. Basically I would like the functionality of displaying "Record X of XX" without all of the other stuff in the Status Area.

Thanks,

Steve

I show the status area unless there is a compelling reason not to, such as an interface design where the form layout used for display depends on a field value, requiring a layout change when records are browsed.

IMHO the argument about wasting screen real estate isn;t valid any more, what with everybody using big wide-screen displays now. And the functionality that the status area offers in Find mode for multiple requests, ommitting requests and inserting symbols is very difficult to replicate any other way.

To answer your question, display the found records in a list view.

An unstored calc field using Get( FoundCount ) and Get( TotalRecordCount ) can be used to display record found status.

Hide the Status Area in Browse Mode

Show the Status Area in Find Mode

<>

This was almost exactly what I wanted...but I ended up using:

Get(RecordNumber)

&

Get(TotalRecordCount)

That gives me exactly what I wnated!

What is the magic trick for remembering all of the different "Get" values.

Thanks again,

Steve

When you specify your calculation change the popup list in the top right to "Get functions"

You can buy the FM Chart which has a link on this site, or you can print out the help section regarding them. The chart is excellent BTW.

We've got one that we use a script to do a find, and the found count goes in the header and we use text, the "double at" ( @@ ) on the record for the record number.

Are there advantages or disadvantages to this?

The one advantage we have seen is that it's in the center of a button with other text, which formats the text & number on center. Otherwise....?

Hi MV

Am i correct in understanding this.

• You have a Find script that sets the found count to a text field

• You use @@ on the layout to display the current record number

I can not see any advantages in setting a text field with the found count. Why not just have the field set up as an unstored calculation

Get ( FoundCount ) ?

I can not understand the last line of your post ? Are you discussing Merge fields ? An unstored calculation can be used as a merge field.

Record @@ of <> found

Hi Stuart

You are correct.

One thing that I didn't mention is that the find script is a little more complicated, and one step in the script is setting the found count field.

These are things that may have been picked up from another project, or may have been something that we did in training long ago ("Hey! can we do it this way?"--"Sure, that's one way to do it.") and I was wondering if there were advantages or disadvantages either way.

To me now, the unstored calc field is more intuitive, but it may not have occurred to me then.

~ ~ ~ ~ ~ ~

No, these are not merge fields. Just a pair of @'s in the midst of a simple button, with some other text.

"Use record @@"

Apparently FM knows what we want there.

Thanks for the feedback!

With the method described i can only see disadvantages

Unstored found count calculation:

Advantage = updates automatically

Advantage = quicker script (one less step)

Advantage = you do not have to create this script step for every table.

Advantage = value is updated if user does not click your button so it is always correct.

-------

Set found count via script:

Advantage = Can't think of any???

I don't believe that Get (RecordNumber) can be used in place of Get(FoundCount). One displays the internal FM record number, and the other displays the current found count.

"One displays the internal FM record number, and the other displays the current found count."

Not quite: Get( RecordNumber ) displays which record we're on in the current found set.

Get( RecordID ) displays the internal record number.

originally posted by Stuart Taylor

With the method described i can only see disadvantages

Unstored found count calculation:

Advantage = updates automatically

Advantage = quicker script (one less step)

Advantage = you do not have to create this script step for every table.

Advantage = value is updated if user does not click your button so it is always correct.

-------

Set found count via script:

Advantage = Can't think of any???

I tend to agree with you on all counts. This is one example of there probably being six ways to reach a given outcome, and with only a little thought the best (or at least a better) way comes to the fore.

Thanks!