When changing the width of columns in many dialog boxes such as Data Viewer, Manage Layouts, etc. the column widths can be resized but when the dialog is closed, the column width settings are lost.
Throwing away user-determined column widths every time a Manage Database (or Manage Layouts, or Manage <anything>) window is closed seems like a problem that, in 2017, we should consider a bug.
I can't figure out why this wasn't changed a decade or so ago. The window remembers what size I had it opened to, but then only uses the first half of the width, collapsing the _name_ column down to something that conceals useful information.
The answer to your question, I regret to say, is one of the most irksome things about FileMaker which has become exacerbated recently with the new "annual release" strategy.
When something has been a persistent problem for many years, they claim that it is not a bug but it is a new feature request because of the number of years that have elapsed during which time it must have been considered acceptable behavior, simply because not enough people complained loudly enough for it to get the attention of the engineering team.
Now, with the annual releases, additional pressure is on the engineers to bring out the new features that will justify the effort and expense that goes into making a new version while at the same time driving new revenue toward those new cool things.
I would point out that when a certain new feature (eliminating the application frame for Windows users) was first shown at Devcon 2015, there was as I recall a sustained ovation, if not a standing one. Now, we finally have it in version 16, advertised as a new feature. Was it a "bug" for all those years gone by? Some would say yes.
I may be a voice in the wilderness on this, but there should be a list made of all the buggy things that have been a source of complaints for too many years, and a special team assigned to wipe that slate clean once and for all. It may not grab the attention of the people who scrutinize, analyze and review new features but I am convinced the developer community would respond positively. I'm not an engineer, but I have a strong suspicion that new engineering would not be required to fix these things.
As an off-topic example, let me mention Custom Dialog Boxes which we still cannot locate and size appropriately in FM-Pro. In previous years, the Show Custom Dialog script step was improved to allow each message choice to commit records, and for button names to be specified by calculation. However, the coordinates and size of the dialog, which has been available in New Window for many years, is still not available which results in users often being unable to see the full message and if they are unaware that the dialog can be resized. Whenever I raise this topic, I am reminded by others in the community that workarounds exist with new windows or popovers, but that's not the point! Many desired results can be achieved more quickly with the custom dialog and it's three button choices than with those other workarounds. Is it impossible to allow the three input fields to use control styles for value lists, e.g. radio button, checkbox, pop-up menu and drop-down list?
Likewise, how much engineering would it take to show the creation date of fields, value lists, tables, and anything else that can be sorted by creation order? The creation date has to be there to support the sort-by. ... why not let us see it? Even more important is the modification date, and how hard could it be to add that? I am in the habit of naming (and constantly renaming) my scripts with date values in order to know which ones were most recently edited without having to open each one and read comment lines. Ugh!
I can't help but observe that yours is a reply to something I wrote here 18 months ago when I was pushed to do so with a long list of things like this. At Devcon 16 I observed how easy it is to correct a grammatical error in a standard FileMaker dialog when I mentioned it to one of the engineers who was able to go directly into the programming code and change "less" to "fewer." I had been posting requests about that one since FileMaker version 3.
I may be a voice in the wilderness
You sure NOT!
Implemented for upcoming https://www.monkeybreadsoftware.com/filemaker/MBS FileMaker Plugin 8.2 for Mac.
Remembers column widths for table, field and layout lists. Permanently in preferences file.
On the other hand, if we could
Manage from Database Design Tables & Layouts (DDT & DDL)
and if
Every FileMaker Pro Application Interface, a Layout Interface,
then we wouldn't be begging for all these little fixes because they would already be there, or we could develop onto a layout ourselves.
Especially true for the frequently used FieldDefs;
I tend to truncate field names so that I do not waste time resizing column widths
Would facilitate better object naming and therefore better code, without having to trade away developer productivity.