Leading Grand Summary Problem

[NickFaraday]

I have a leading grand summary in a layout that shows standard fields (not summary) from a related table.

In the Leading Grand Summary only half of the fields are editable for some reason?

Ex: the fields in the lower half of the LGS are editable and the fields in the upper half are not? All records come from the same related table, and have a one to many relationship.

All fields have the same perm, and are editable in browse and find mode, there is nothing layered over them. I have rebuilt the layout 3 times and get the same thing every time? Once more if I take a field from the upper half of the summary field and move it to the lower half it becomes editable?

Any Idea what is happening here?

[comment]

Can you post a simple file showing this?

[NickFaraday]

I have attached an example of the problem... 1 zip 2 dbs.. one GUI one Data... open the GUI to see the issue.

Example.zip

[comment]

No, I meant a SIMPLE file. I don't get your file at all. Why does showing all records make your data disappear?

[LaRetta]

Your layout is based upon General_List_Components (which has 4 records). But all your fields in the BODY are based upon your related table Shipping_list. There is not a single field in the body which is based upon the table of your layout.

Your layout, if you want to show Shipping List records in the body, must be based upon Shipping List.

UPDATE: In addition, General_List_Compenents is two relationships away from Shipping_List. I don't know what to suggest because I can't figure out your file but I think you should try changing the layout so it is based upon Shipping_List.

Edited April 9, 2008 by Guest
Added update

[LaRetta]

I too suggest that you provide a new clean (simple) file so we can see the specific tables you are working with. Listening to Comment is always a solid decision.

[NickFaraday]

To base the layout on Shipping list seems like the way to go but I'm building a list of media that is intern shipped. There is no telling how many bits of media will be in any given list so I can't simply use a portal b/c it may not print all media attached to a shipper...

Sorry about the DB, that's about as simple as I can par down this database and still replicate the problem. It looks to be a bug in FM from my point of view, as there is no reason for positioning within the same "Part" to affect the behavior of a field.

On a side note no buttons work in the upper half of the LGS either.

[NickFaraday]

Why does showing all records make your data disappear?

That's one of the funny "features" of filmmaker, lol.

Leading Grand Summary will populate any normal fields (non summary fields) with data in the first available record.

In the example, the first record in General List Components is related to a different type of list, not a shipper, since there is no shipper data in the General list table the fields are shown empty.

[Vaughan]

"On a side note no buttons work in the upper half of the LGS either."

A couple of things:

1) summary reports only work with the records are sorted correctly (by the sub-summary break fields, in order from top to bottom on the layout) *and* are either viewed in Preview mode, or printed;

2) buttons don't work in preview mode;

3) issuing the Show All Records command will unsort the database, and summary reports only work when they are sorted correctly.

[comment]

I have reproduced this in a simple file, with a single table and no separation. I have a vague idea why this behaves as it does, but...

The taller you make the body, the more fields in the grand summary part become enterable. Moreover, if you have more than one record showing, it's possible to move from record one to subsequent records by clicking in the upper parts of the grand summary. It's as if the body part were "mirrored" beneath the grand summary part.

Compare with:

http://www.fmforums.com/forum/showtopic.php?tid/188674/post/284307/#284307

It could be called a bug, but the conditions are so esoteric that... I mean, who cares. My conclusion would be that summary parts are not meant for data entry.

[NickFaraday]

1) summary reports only work with the records are sorted correctly (by the sub-summary break fields, in order from top to bottom on the layout) *and* are either viewed in Preview mode, or printed;

Not sure if this is relevant or not, I'll look into it. The fact that half for the LGS works and the other half doesn't leads me to believe there is a bigger issue going on here.

Simply moving a field from the top to the bottom of the LGS causes the field to become active again.

2) buttons don't work in preview mode;

But they should work in Browse mode which they don't.

3) issuing the Show All Records command will unsort the database, and summary reports only work when they are sorted correctly.

They also work when data is filtered (Subset)

[NickFaraday]

It could be called a bug, but the conditions are so esoteric that... I mean, who cares. My conclusion would be that summary parts are not meant for data entry.

There are a lot of these types of "bugs" in Filemaker... makes it hard to develop when you come from more traditional DBMS environment.

How does one create a layout that is flexible enough to show an undetermined number of records in a "list", that also has a "Leading Header" at the top of that list?

Also, I'm not so concerned about data entry, but I would like "button" functionality in the header section, which is also not functioning.

Oh, and thanks for the help you guys.

[comment]

Use a header part instead.

[NickFaraday]

Use a header part instead.

Wrong type of functionality. "Header Parts" show up at the top of every page. If I have 100 parts to a shipper I can't have half of every page showing the same data over and over....

[comment]

Wrong type of functionality.

Indeed. I was responding to:

I'm not so concerned about data entry, but I would like "button" functionality in the header section, which is also not functioning.

Buttons do not work in Preview mode. "Pages" exist only in Preview mode (and of course, on the printed output - but I don't think you expect buttons to work there either... : ).

You probably need separate layouts for browsing and for printing. You can have buttons in the header section in the browse layout, with a continuous scrolling list of records beneath. For printing, you can use a leading grand summary, which will show summary data ONCE, followed by your 100 parts divided into pages.

[NickFaraday]

You probably need separate layouts for browsing and for printing

I think your right... inconvenient, having to design two layouts for one "function", but I guess it will have to do.

[comment]

It's a quite common arrangement, I think (esp. since print layouts often use fonts too small to be read comfortably on screen). In any case, what you describe is certainly NOT one function.

[David Jondreau]

I agree it's not a bug per se, but just the wrong tool for the job, or maybe a wart. I suppose FMI could have programmed it so a Leading Grand Summary wouldn't show in Browse mode like a Sub-summary. Maybe there's a reason for that.

But I've been developing filemaker for a while and I've never used a leading grand summary in browse mode, I don't know what use it is, rather than a "Header".

comment's analysis seems pretty good: The "enter-a-bility" of a field on a Leading Grand Summary is determined by the size of the body.

That reminds me of the sizing of layout parts when trying to get a record hilited in list view using Conditional Formatting (nee Trailing Grand nee Web Viewer).

Buttons do work on a Leading Grand Summary in my copy of FM9A but not FM8.5A. Weird, but irrelevant. Use a Header part.

There's a difference between summary Fields and summary Parts and summary Reports. It's been one of the toughest set of features for me to wrap my head around.

[NickFaraday]

Ya, I guess you can consider browse and print two separate things(makes sense), regardless its more, and in my opinion unnecessary, work...

Thanks for pointing me in the right direction.

[David Jondreau]

I think your right... inconvenient, having to design two layouts for one "function", but I guess it will have to do.

I would think Browsing and Printing were different functions.

FM gives you the tools to make very ergonomic interfaces. The display of printed information almost always has different requirements than that of a data entry situation (and simple display for that matter).

[comment]

That reminds me of the sizing of layout parts when trying to get a record hilited in list view using Conditional Formatting

Ahem. I thought I have already linked to that thread.

Buttons do work on a Leading Grand Summary

Buttons work in the same region where fields are enterable. I don't see a difference between 8.5 and 9 here.

[comment]

I guess you can consider browse and print two separate things

Well, actually I meant that since you want buttons for one and summary data for the other...

[David Jondreau]

Ahem. I thought I have already linked to that thread.

Clearly, I'm not so good at following links before posting.

Buttons work in the same region where fields are enterable. I don't see a difference between 8.5 and 9 here.

That reminds me of the sizing of layout parts when trying to get a record hilited in list view using Conditional Formatting. :

Twas differences in the 8.5 and 9 test file part sizes.

: :

[comment]

LOL