Creating a "table" with a List View

[Mandu]

I haven't been involved with FM since V8, but back then it was really hard to set up a List view that looked like a Table. In V10 it's just killing me.

This must be something virtually EVERYONE wants to do at some point: create the appearance of a Table, with horizontal and vertical lines as separators, using a List. Why? Simply because you can do more in a List view.

Mind you, it's not hard to make a sloppy-looking one. If you don't care if the vertical line segments have a "dashed" look, instead of flowing smoothly into an unbroken line from top to bottom, it's easy. But I -- and I daresay a lot of FM developers -- want it to "look good."

Can anyone provide a recipe for laying out the "body" of a List view containing nothing more than equal-height text fields, vertical line segments for column separators, and a horizontal line as a row separator?

By "recipe" I mean something along the lines of “let the Body’s height be n pixels. Then, choose a font size of n-2 and make your text boxes n-1 in height. The vertical separators should be n-1 in height and should be positioned vertically at ....”

PseudoTable.fp7.zip

[Vaughan]

Have you tried table view?

What you want can be done. The trick is to make sure that the objects in the body such as vertical lines do not go into the header part: the top dotted line border at the top of the body is the last pixel of the header.

[comment]

Or:

PseudoTable.zip

[Mandu]

Hmm - simple but effective - I like it!

At some point in the dim dark past, I thought I had a need to make the vertical lines independent of field borders, which is why I got in the habit of using vertical line segments. But until (if ever) I remember why, I'll just use field borders as you suggested.

Thanks!

[Mandu]

Unless I'm missing something, I can't put a button into a Table.

[Mandu]

  Quote

The trick is to make sure that the objects in the body such as vertical lines do not go into the header part: the top dotted line border at the top of the body is the last pixel of the header.

I think that it's the hairline lines that really give me trouble.

A 1-px line, when drawn, includes the tiny squares that appear at each end in layout mode, whereas a hairline is drawn to exclude those tiny squares. Therefore, it seems to be impossible to make a hairline extend fully from top to bottom of the Body - there's always going to be a 1-px gap at the top (see PseudoTable.fm7)

[bruceR]

  Quote

I think that it's the hairline lines that really give me trouble.

A 1-px line, when drawn, includes the tiny squares that appear at each end in layout mode, whereas a hairline is drawn to exclude those tiny squares. Therefore, it seems to be impossible to make a hairline extend fully from top to bottom of the Body - there's always going to be a 1-px gap at the top (see PseudoTable.fm7)

And if you put the horizontal line at the top...?

PseudoTable.fp7.zip

[Mandu]

That works! Along with a bottom line, to cap off the final row.

[truthiness]

Thanks for submitting the sample file!

It works well for single line data, but what if the data is of variable length?

Say your database had a notes field & it was filled with various amounts of data. The field could have a fixed size like the ones in you sample database. But this may not show all the data so this is not an ideal option.

You could make the Notes field large enough to accommodate a lot of data & use sliding to resize the field based on the data that's contained. But sliding creates a problem because the other fields like the City field contain only one line of data. So in Preview you'd see a long vertical divider on the Notes field & short dividers between others with blank space below them. You would not get a contiguous table.

I've used some workarounds for this but it's way too much work for something seemingly simple. Anyone found an easy way to address this?

TIA!

[comment]

I don't know how to answer this, because I don't know what workarounds you have used. It certainly requires SOME work.

[truthiness]

Well in this example, since only the Notes field will be large I can duplicate it for each divider, send them to the back, set the left border & make the text white. I don't like this option but it works.

In some cases I'll go so far as calculate the line breaks & pad all the other data.

For example, if the Notes field in a given record wraps to 3 lines, then I'll add return characters to the other fields so all the fields contain the same number of lines. Or I'll add a calculation field that only contains returns & use its border to create the divider. These are terrible workarounds & usually not worth the considerable effort to implement.

I've also pulled FMP data into reporting software (like Crystal Reports) or generated web pages & used the web viewer but again this is only when absolutely necessary.

I've never come across a clean, easy way to provide this seemingly simple & obvious functionality in FMP. But it sounds like you have some easier solutions?

[comment]

No, actually I was going to suggest your very first option.

[Vaughan]

The only way I know of to get variable height vertical lines is to use borders on the field objects themselves.

I gave up on vertical lines in variable height list reports long ago. Too fiddly... very little roi...