A layout folder is, in fact, a layout object in the internal database schema. This is why you're seeing what you're seeing. A layout folder won't have any fields on it, so the list comes back blank.
I was wondering if that might be the case. I know the same is true of layout separators (that they are layout objects under the hood). Those actually show you the base table, and you can open the layout. Folders they hide a little better, which is why this was such a mystery.
I see; I'm sure you're right. Feels like a hack to me. I did a little digging and layout folders was introduced with FileMaker 11; if memory serves, we used to separate layouts with blank layouts that started with a dash. Maybe FMI just decided to hijack the old structure…
I wonder if the FieldNames() function could be updated to exclude these special folder layouts? In the mean time, I'm forced to rename all of my folders to make this function work reliably.
FWIW, I generally create a layout (not a folder) matching the name of each base table for maintenance purposes. It makes it much easier for DRY scripting.
You can also use Get ( LayoutName ) to fetch the current layout name instead of hard-coding it, if that helps.
"Dry scripting"… that's a new term for me.
We do something similar but we prefix such layouts with a "Dev -" prefix followed by the actual table name.
The ability to pull ALL field names is actually quite useful in some cases. My current situation calls for the syncing of all record data to an ESS table. My plan is to grab all field names from my source table and loop through each, populating the matching field name in the ESS table via Set Field By Name step. This would be made much more tedious if I had to set up my layout with the fields I wanted (assuming I was using the FieldNames() function) or using the explicit Set Field step.
But the purpose of this particular exercise was to get a list of all of the fields in a table. If you specify a layout name, you only get the fields that are on that layout. If you specify a table name (that is not the same as a layout [or layout folder] name), then you get all of the fields in that table.
DRY = Don't Repeat Yourself. Basically, a mindset of using abstraction to avoid repetitive coding. By having a single layout that has all the fields for each table, you create an anchor point for lots of useful stuff. For example, you can say Go To Layout [ Get ( LayoutTableName ) ] and automatically navigate to the maintenance layout corresponding to whatever layout you're on, with assurances that the layout exists and contains any field you need.
However, if all you want to do is pull the field names associated with a table, you can do that by querying the virtual schema via ExecuteSQL. Here's a related thread that discusses how:
I would say that it is a bug that resulted from leveraging pre-existing structure to more easily implement a new and useful feature.
That said (and I feel your pain), we might consider it a low priority bug to fix in that there is an easy work around. We use <Table(Occurance)Name> + " ->" or to use your example "TestTable ->"
We started using this naming convention in FileMaker 11 as there is/was a danger of someone opening a system in FileMaker 10 (or below) and deleting the "blank" layout. Same risk with script folders based on version. Tony White Designs: FileMaker 14 Code Objects as ERD
My guess is that FMI would have to fix a bunch of APIs to address side effect.
Plus, I like the user interface that you get with appending " ->"
Hope that helps.
Doesn't Get ( layoutTableName ) return the name of the TO, not the base table name?
Yes, that is a consideration.