Yes, I'd like the OPTION of not seeing/using it (by layout) in the layout TABLE view.
But if you right+click on the column, you should be able to select the column width and manually choose a size that is wide enough.
in FM12, this is "Table View", "Set Column Width..." in the contextual menu.
in FM11, this was just "Set Column Width..."
That is halfway to getting round the issue, if I remember that littel menu item next time!!
This is not uncommon... the right-click for options on whatever you click on...
It has applied to FM objects for a very long time... certainly in Layout mode.
It has also applied for many applications/programs and OS components on both Mac and PC for years and years and years...
Very useful ye-olde right-click :-)
I'm still finding it difficult to substitute behaviour with my old command-dragging objects. Simply dragging is too easy...
What's that about "old dogs..." and "new tricks" ?
There was a great article in MacWorld probably issue number 1 or very early at least called "IBM RAMBO Meets the Mac". I sneered at his inflexibility.. probably about 25 at the time. Now in my life, I relate to him. If it 'aint broke, why fix it' I am prone to think. The challenge his is to overcome the change... own it... and know that you provide the best evidence of your intelligence which used to be defined by the UN as "the extent to which an individual can adapt to new conditions and environments". FMP 12 is a big change... but we've done it before...
Here's an "idea" which removes the ability of accidentally adding fields in Table view. This is done without using a privilege-based approach. As a developer I've accidentally touched that right hand boundary and I agree it's annoying when an extra unwanted field is created!
Also I'd prefer to work with full access without exception or interruption.
Knowing that in a separation model, tables coming from "external" data sources are immune from this "problem", a simple approach is to go into Define Database, double click the TO which your layout is based on, then redefine its source...
So, rather than being based on a BaseTable in "this" file (your current file), define a new Data Source, and when you do so, nominate it to be "this" file (ie. your current file).
You'll see that the TO now appears in italics.
Now see how Table view looks. That pesky thing over at the right hand side is gone! Another bonus is that, unlike a "real" external file, you don't compromise the ability to directly "Manage Database".
It seems to work without problems. But I haven't tried it in a real world situation or put it through any rigorous testing and would be interested to learn of any real issues. (I know this means if you ever change the name of this file, you will need to also correct it as a data source).
There's always the laid-back, go-with-the-flow approach. Once you've created that new, useless field, shrink it down and just leave it there as a buffer.
Proper clever outside the box
This must be a case of stupid meets stupid. That suggestion sounds stupid to me. No offence meant, I just want to put it on record.
Ralph, I was a little worried about this approach. What if you MOVE the file to another location (folder)? Well, I tested the theory and it appeared to be ok.
this changes to (where the table is made an "external source"):
This is just on my local drive and moving the closed database only changes the SOURCE FILE to the correct path. So, my worries about that went away.
I have NOT tested when HOSTED on FMServer. I would be extremely curious to see if this is a problem (or potential problem). And I'd also like to hear from other developers why or why not use this method?
Since I generally use the separation model (data files and interface file) for most of my solutions, I do not get the "+" in table view on layouts designed to use table view.
Interesting technique, though!
That's working on a Mac. What about on Windows? What about shifting across volumes? What about renaming the file from data2011 to data2012?
It's my opinion that this technique is trading a nuisance for a liability.
Yes, that is my question/concern. Would the method work in these case? & What do fmi engineers say about changing a "" to a "virtual external source".
Malcom, when these conditions are applied to a REAL external source you know what needs to be done (i.e. renaming file -use dev tools) and I would assume it applies to using this method.
Malcolm, when these conditions are applied to a REAL external source you know what needs to be done (i.e. renaming file -use dev tools) and I would assume it applies to using this method.
I still have the scars that come from doing this the wrong way but I think that doing it the wrong way is more common than it should be.
OK, so it's a week later and I'm with Malcolm, in concern for changing a "local" file reference to "external" just to avoid a problem.
and experimenting, I found that other than the right+click to change the column by contextual menu there is another way to resize the LAST COLUMN:
(HA HA! I'm not sure I'm recommending this either, but here you go....)
go ahead and let the "+" create another field/column, resize the one you really wanted to resize anyway, then delete the newly created field (contextual menu again!)
I said it was different.
and it does not prevent users from being allowed to create (without other means).