I am not aware of such a possibility, and would anticipate problems with doing this if a way were available:
It's fairly common to need more than one object on a layout referencing the same field definition for some interfaces, so I am not sure what would get named if you could referenc by field name. However, it's fairly rare to need to have every object on a layout named, and I wonder how you would keep track of all of the names so your could reference the correct one later if you were to name everything.
I suspect you would still need to go into layout mode to check the object's name(s) so you could reference it correctly. Naming as-you-need-it (the current option) seems much simpler in the long run.
Just my opinion.
That sounds to me a very inefficient use of your time.
What is not clear is why you need to calculate so many go to field events...
For starters... you can calculate with if statements inside your scripts...
... you can also set the tab order.
Really trying to understand what you are actually trying to do so perhaps we may be able to suggest an alternative methodology.
Its a 50:50 but if you are on a mac you can use applescript, literally put:
go to cell "field" of window 1 of database "myDB.fp12"
in the perform applescript scritpstep and away you go.
Awesome, that works great! (I used a calculated AppleScript to go to a field name specified in a variable.) Thanks very much.
Yeah, change the hard coded references for certain, and you certainly want to wrap that in a custom function to make it easier to maintain (for example the syntax changes) so you only have the code in one spot.
If statements would be another way to do it, but lots of fields mean lots of clicking/typing for all the if/else if/else if... possiblities. (Back in the FMP4 days, there was a third party app that let you type scripts in a text editor, and then the app would import them into the DB. That was awesome for things like writing long strings of conditionals like that. But I don't know of such an app for 12.)
DamianKelly's Applescript idea is better than a series of ifs, and also better than my idea of naming objects, because if new fields are added to the DB, the applescript method can go to them without needing any additional setup (like naming the new field-object or adding another conditional).
I hadn't thought of that but you're right of course, Go to Field By Name wouldn't necessarily put you in the right place if the same field appears more than once on a layout. In that case, object names would be the way to go. (Kind of like Go to Portal Row, which makes an assumption about which portal, if there are more than one on the layout and there isn't already an active portal.)