FileMaker 13 now allows you to make an object invisible based on a calculation. This handles the general layout issue, and related pop/picker windows to select items is a general way to deal with this. Value lists also have the ability to insulate the user from the ID... However, the concept that the customer is always right is pure nonesense. There are time when the customer needs to be educated, or else, you will be put in a position that makes them harder to support. Having an ID visible can help with diagnostics. They can be put on layouts without being obtrusive.
Sounds like a particularly cantankerous customer you have there. I have a customer who hates drive shafts, hates them with a passion. They never want to see one anywhere in their car. Ever! I have to explain to them that I do my best to hide the drive shafts from them, although I can't hide them completely—like that little bump in the middle of the floor. But I also tell them that the car really won't work without them, so they just have to be there somewhere. Sorry, but that's just how it is. Most of the time they can drive around blissfully unaware of the fact that it is the drive shafts that are actually enabling the car to move.
Customer re-education is probably your solution.
You're doing something sincerely wrong. ID fields are never requested to be present on a layout. What is it that you so desperately need them?
Where possible I often try to shield clients from ID numbers. But schema and joins require them in many cases and not using them causes other problems like if you use a company name as the ID and someone changes the company name - haha. Actually, lately I have started using UUIDs instead of serial numbers. This is particularly good for mobile solutions that have to later sync data to make sure their IDs don't take a serial number that had already been assigned. The draw back to UUIDs is tha they are very long and too long for a client to see a useful ID they can recognize. So all the more reason to hide them from the end user. And as wsvp reminded you, the new "Hide" feature is good for hiding fields such as the ID if you are not say a "[Full Access]" developer, etc.
Yes you are correct if the ID field lives on the same layout as the Table.
However if you have 5 tables where the client needs a report that uses informationf from all five tables, now I have to create a report table and in the report table I have to push data from the other 5 Tables to the report table and I use the ID's to navigate to each table, capture the data then pushing it to the report table. And the only way I can navigate to each table is from preselected value list that hold key data ( ID fields ) Again customer HATE looking at thses fields so I hide them behind the Name field associated to the value list ID fields and change their color to the back ground. One color portals no problems, but alternating portal colors show the OFF color ID fields.
So a simple example, Projects Table, To Do Table, User Table. Now the clients want to assign many users to one To Do, So now I need a ToDoUser Table that lists all the User Names along with there ID's and on the same Record I have to have the Name of the To Do assigned to that user along with the To Do ID.
Now neither the To Do ID nor the User ID belong to the Project in a sense yes they carry the Project ID and Project Name associated to the User and ToDo in the ToDoUser Table and the only way to gain access to the To Do and User ID and to assign correctly is to use a value list where the FIRST value is the ID and the second value is the Name ( Human Being ) for borh User and To Do
So now, the customer wants to change users assigned to each To Do ... as you can see, to populate the ToDoUser Table I must have the New USER ID the customer selects from within the value list along with the ToDo ID which neither ID belong to the Project table. Yes they are on the Project Table.
Again, customer are not insterested in seeing these ID fields and I hide them behind the second fields ( Name )
Anyway, all I'm asking is that Filemaker provide a way for me to remove the color from Text within "A" fields similar to removing the "Fill" color of an object.
I mean MY GOD MAN I am allow to select every other color know to ORGANIC matter except NONE. Hahaha ...
I'm not the one who is crazy, those who except that the earth is flat well ... I guess ... they have New Front Wheel Drive with NO DRIVE SHAFT!!! Imagine that ... heheheheh
Has anybody located that "Clear" color palette yet ??
Yes, the value list can insulate the ID inside the actual drop-down, however, the resulting ID is what is displayed in the object if using a drop-down list. Not sure on PC, but on the MAC you can use a Pop-up menu and the second field is what is displayed, not the ID field. I like the object visibility option.
I apologize if this shows up twice - thought I posted it but the comment didn't appear.
Set your ID field hidden behind the name field. The name field can be a button that runs a script to set the ID field visibility on, then go to the field. The value list can be set to show secondary value only. The ID field can have an onobjectsave/onobjectmodify trigger that sets the object visibility back to hidden and goes to the next field.
I can think of at least three ways to accomplish what you're trying to do.
The simplest is to use a popup menu with two fields (ID and value) and "Show only second value" checked.
You could also have a field for user name that looks up the ID, either by relationship or by search.
You can make the ID "invisible" using conditional formatting by changing it's font size to 500.
The fiirst two I've done before and works great as long as the back ground color is the same where I can color the text the same, but with the Themes using Gradients and / or choosing Alternating Row Colors in a Portal I am unable to hide the field just by color.
However, changing the font to 500 is what did it!!! There is NOTHING IN THE FIELD AFTER SELECTION !!!! :-) Spectacular!!!
Again, thank you so much David.