Without meaning to be obvious, does scrolling down in Layout Mode show the fields further down? I ask because your screen shot of Layout view shows that you are seeing the very top portion and there's lots of scrolling down possible. This indicates to me that there are objects lower in the view. Otherwise scrolling wouldn't be necessary or possible.
It is possible to use the Modify button to add fields to a table view without adding them to the layout. If you then enter layout mode, fields added in this fashion do not appear on the layout. This is normal behavior for FileMaker.
In general: Table view is very usefull for a lot of 'admin tasks', ie an 'admin layout' to have a 'core view' of the data from one table.
But that's it, I never use table view for other purpose (yes, there might be exceptions). The ability of adding fields -even create fields- in a view is something like 'the tail is wagging the dog'... Maybe this FileMaker-method (table view) is just not ready to use, not finished - but 'as is', there are a lot of problems when end-users are using those beside of admin-purpose (create a field an then delete that - a 'field missing' text appears, fields are visible in the table-view but *not* in the layout, etc).
In a table-view, one loses related data (1:n,), no visual workflow, etc. There are many differencies between a spreadsheet and a database (-:
(I'm writing this because of an increased number of user problems during the last few months)
I find Table View to be a useful tool for me as the developer for getting a quick, flexible overview of all the data in a found set as a way of better understanding why a system is/isn't working as expected, but I use List View when I want to present the user with a tabular view of their data. It's not as flexible in some ways as table view, but I get design options not possible in table view and I can compensate for some of the lacks with buttons and scripting. (And I never have a user "lose" a column due to resizing it to small to see...)
No, scrolling on the layout does not reveal any fields. Also, changing the theme has no effect.
With regard to our use of table view, we generally use it as output for PHP files on our web server (via the PHP API). It's clean and efficient. In fact, our web programmer/analyst discovered this change in behavior. He's written hundreds of php files that call my tables (from layouts in table mode).
The smoking gun, if you can call it that, is the fact that FMP12 and earlier versions do not have this behavior.
Also, it's a bit uncomfortable to realize that layouts created in FMP13 in this manner are now somewhat damaged, if you will, and will have issues across multiple versions of FMP. So we're just creating layouts now in table view, saving, then changing them to good ol' table view.
But this is not the case. Table view has always worked like this since it was first introduced. Using the Modify button to add a field to the View does not automatically add it to the Layout. And this does not damage the layout in any way.
Let me first say I didn't intend to sensationalize the issue by using the word 'damage'. But it was best word I could come up with to describe a layout with inaccessible fields in all versions of FileMaker.
I also don't think your point about the table view's behavior is related to this particular issue.
I've attached an image to clarify the issue we discovered for anyone who is researching this. Forgive me if it's a bit hard to see.
There are design differences between FMP12 and FMP13 with regard to creating new layouts. However, the end result should be the same and behave similarly. They are not.
In FileMaker 12, creating a new layout brings up the New Layout/Report dialog box (with four pages). On page 1 of 4, the layout name and type (standard, table, list, etc.) is selected. Page 2 of 4 selects the fields and order. Page 3 of 4 selects the theme. Page 4 of 4 determines where the user lands after the layout is created (browse or layout). When creating a layout with a table view using this structure, the result is what I deem "normal", meaning this layout will show all the fields selected upon creation in both browse and layout mode. The resulting layout functions as expected in FMP12 and FMP13. I have tested this.
In FileMaker 13, it seems the process to create a layout has been overhauled to likely accommodate various devices. Instead of four pages, there is a single page to name the layout, select the device and layout type. FileMaker 13 then pops up three dialog boxes. First is a prompt to save the changes to the layout. Second is to add fields. Third is to order the fields on the table view. All of this works. However once the user switches to layout mode, the fields that were added to the table layout are nowhere to be found. Worse, if this new layout is loaded on an older version of FileMaker, the fields cannot be accessed there.
We do not feel this was the behavior that FileMaker engineers intended. The reason we feel this is because it functions differently in FileMaker 12, and because creating a form layout using the same interface on FileMaker 13 yields a layout mode populated with fields.
If you make a table layout in FileMaker 13, but choose NOT to populate the fields using the pop up boxes, and later add fields by dragging them in to a saved layout, it behaves as expected.
I hope this clarifies the issue for the engineering folks.
Thank you for a much more detailed description of the issue. That clears things up a lot.
I just ran a quick test to see this in action. I see what is happening and why, but believe that this behavior change was an intentional design change by the developers. A TS person may reply and correct me, but the design wizard clearly selects the Modify option for you in order for you to select fields for your table view. And then, as I explained from the beginning, these fields are added to the view rather than the layout and thus will not appear when you enter layout mode. Since no fields were added to the layout by this sequence, opening the file in FileMaker 12 will also not result in fields appearing on the layout while in layout mode.
A quick check in FileMaker 12 confirms what you report, that the new layout wizard in filemaker 12 adds the fields to the layout as well as to the view. But the fields are just placed in a vertical list, the result is not particularly useful for any view but table view and you can easily put the same fields on your layout in FileMaker 13 by using the field picker while in layout mode.
There are only two reasons where you need to add a field to a layout used in Table View:
1) To specify a format for the field--such as conditional formatting or a value list format.
2) You also intend to use the layout in form or list view as well as table view.
So I do not see any bug here myself but rather a deliberate change in designed behavior. If you want to see a change in future versions, I think that you'll need to submit a feature request for it.
Thank you for the post.
PhilModJunk is correct. This was an intentional design change. Also, "if no options are selected, a blank layout will be created if the Finish button is selected."
"If you click Finish in the first panel of the New Layout/Report assistant without choosing a layout type, FileMaker Pro creates a blank layout in Form View. A blank layout contains no fields; you add the fields you want in Layout mode."
Like PhilModJunk mentioned "Table" is not a layout type but a view. Notice in your screenshot that the "Form" view is active in the newly created layout in FileMaker Pro 12; however, now by default, in FileMaker Pro 13 when creating a new "Table view" the "Form" and "List" views are disabled.
Additionally, "by default, the preference "Add newly defined fields to current layout" will be unchecked. If enabled, new fields created in the Field Picker will automatically appear on the layout."
Lastly, here are the knowledge base and help articles sited above:
Thanks for this, I'm a newbie to FIlemaker and it's extremely confusing that my table refused to show up in Layout mode - just completely missing.
I feel this is not well-documented in the training materials, that is my new issue. Actually, I'm happy to help correct that problem if anyone is reading this...
Thanks again to everyone for their explanation of this 'feature' of table view.