AFAIK, you would have to make a separate layout for each user to allow them to preserve their own preferences. Else, if you are allowing them to make changes to the layout, it's the same as letting them edit the layout as you do: any changes are applied to all users views.
There might be a way to do this, but it would be a bit of work. Here's how:
Set up, instead of a table view, a list view. Make your column headers global fields. Make the list components calculations via the Virtual List technique.
Then, here's the tricky part: You'll need to implement drag-and-drop using Script Triggers so the column headers can be re-ordered by the user. By grabbing one global field and dropping it onto another, allow the script that the trigger executes to re-order the column headings, which will then cause the columns in the list view to recalculate.
Of course, this will only work if your users don't need to edit the fields in question. But, for display purposes, it's at least theoretically possible. Details to be worked out.
Thanks Mike. I just found that out watching the 12 days of FM 12 on table views. It was the last thing that was covered but just what I did not want to hear. It would have been a huge plus for the users to be able to arrange the columns as needed and then retain that setup for them. Oh well...thanks for responding!
Thanks for responding Mike but that is way beyond me at this point. Still a baby developer and I bit off way more than I can chew for my first project. But if I can pull it off it will revolutionize the way my group works. I'll just add that to the list of future enhancements! Unless you've got some free time at DevCon this year. Then I'll bring my laptop and the food and be glad to sit on your shoulder and learn as you work some magic!
Sadly, I can't attend this year. But I'm sure someone smarter than I can help. There are certainly plenty of people who qualify at DevCon.
One thing I just thought of, if you use the data separation model, you could just provide a copy of the interface locally to each user. This would be hard to make ongoing changes to, unless you only put this table view in it's own separate file.
IE: have your hosted file: main.fmp12. When someone clicks the "table view" button, it opens up a local file called "userTable.fmp12" that uses main.fmp12 as it's data source. Button within userTable.fmp12 would direct user back into the hosted main.fmp12. You would then give a copy of this userTable.fmp12 file to all users in a specific directory (IE C:\fmlocal\userTable.fmp12 ). Any changes to userTable.fmp12 would require you to have the user replace that file locally on their machine (and subsequently lose any customizations), but you would retain the flexibility of being able to make/deploy changes in your main.fmp12 file.
Thanks Mike. Not sure I can trust my users with that option. I currently have 180 users which covers the Americas and I am working to take this global. I will test it though.
Sent from my iPhone
You might want to consider Mike Mitchell's method below in that case. If you're developing a robust product for worldwide distribution and this is an important feature, then it might be worth it to invest the time to build something that complex.
It could be worth it for you to hire a filemaker consultant to do the beta of that for you. Elance is a good place to find people like that.