More and more functionality depends on layout objects being named. Instead of new objects having no name by default, it would be nice if they were assigned some name, even if it's "object 1", "object 2", etc.
Partially the same as
Go to field by fieldnames and/or automatic default object names
I would personally not like to have this, but if there was a FileMaker > Preferences toggle to activate it, sure.
Maybe it could be possible to have new object names defined using some kind of formula that could reference the type of object etc? That would make it a bit easier to have object names respect naming conventions.
I like both these options.
My comments and suggestion:
My comments and suggestion:
NO Option under FileMaker Preferences -> this would lead to a USER being able to change the behavior of a delivered database!
This is sort of a totally different topic/feature request, but what we really need is a totally new are "developer defaults" for a whole range of behaviors. In a way, I'd want these both on the application and the file level, but if I have to choose, rather on the file level with an option to import or copy/paste between files.
And in addition, it would be nice to be able to hide Preferences on the Mac natively... or else those settings should be moved to some other place.
And one guy's naming convention is an other guy's (or gal's) nightmare... I would e.g. most definitely want the object type in the name, and I like to use it as a suffix, since it's mostly important for programming purposes/uniqueness, not important to the eye.
I do like your idea of distinguishing automatically added names from manual overrides. I wouldn't mind having a "fallback" auto-generated name if I can indeed override it.
Good thoughts. Like CamelCase points out, we all have variations in our naming conventions. What you describe sounds like great "generic" names, that we could change manually if we needed to. I would think that for most of us it'd be pretty obvious if the name were using our special naming convention or the defaults, but indicators are a good idea on principle.
As for FM preferences... This wouldn't actually change an existing solution, as I wouldn't imagine such a setting would be retroactive. I'd imagine it'd be like the settings for "add newly defined fields to current layout".
I'd also agree with CamelCase that a "developer defaults" panel would be way better for this sort of thing. Perhaps that's a separate product idea, CamelCase?
(The rest of this rant is about that possible new product idea, so pack your bags, we're going on a tangent.)
I could vote something like that up. Bonus points if we could export and import those defaults. My undying gratitude if I could import a set of these preferences on someone else's machine and have them only last until I quit FM.
Various defaults that drive me crazy include the Enter Find Mode script step (pause? really?), Go to Record/Request/Page [next] (when would you NOT want to exit after last? Ever?) and more.
Separately, as a developer I end up developing on other people's computers an awful lot. That "add newly defined fields" option has led to some pretty screwed up layouts (especially before "undo" got better). Like wise the "save layout changes automatically".
It'd be nice if I could set those various defaults and preferences, then export them to a handy file. When I install a new version of FM, or set up a new machine, I could import them. Then, if I were working on someone else's computer (a client, or helping out another developer) it'd be great to be able to import those settings but have them revert when I quit, so I don't overwrite that user's preferences permanently.
Good one, CamelCase... got me dreaming a bit.
I would also say that object_1, object_2 etc would be better served by using the object type instead of generic "object"
i.e edit_box_1, calendar_2...etc
with this Extend the GetLayoutObjectAttribute() Function
Retrieving data ...