FMP Adv. 11, both platforms:  I wonder if there's a setting I'm
overlooking that would make the left-hand column in table view
disappear?  This is the column with the arrow that shows which record
is active.  I don't need it, and I'd rather have the extra pixels
horizontally.  Anyone know if there's a way to turn it off?

Thanks,
-J.

In article
<4b549d30-8237-44ef-b2eb-2b2ec6ccaf03@h36g2000pro.googlegroups.com>, jahn
<jahnbigbooty@yahoo.com> wrote:

> FMP Adv. 11, both platforms:  I wonder if there's a setting I'm
> overlooking that would make the left-hand column in table view
> disappear?  This is the column with the arrow that shows which record
> is active.  I don't need it, and I'd rather have the extra pixels
> horizontally.  Anyone know if there's a way to turn it off?
> 
> Thanks,
> -J.

I'm not sure if it's been changed in newer versions, but in the older Mac
versions I use both "Both As List" and "View As Table" modes use a thin
black bar on the left-hand side to indicate the current record. (I've just
checked my FileMaker 5.5 has the black bar in Table and List views, and I
know FileMaker 7 that I was using elsewhere earlier today has the same
black bar in List view, but I'm not certain about its Table View - I've
never had a use for Table View, so I've never looked).
It could be that in "Table View" they've changed it to an actual arrow (to
match Access). You probably can't turn that off, but you could check "List
View" to see if that still uses just the bar, and if it does you can fake
your own "Table View" using "List View" instead.

Helpful Harry  :o)

Hi, Harry -

The arrow column in Table view is new as of FM 10 (if I remember
correctly).  List view loses three pixels on the left side; Table view
loses 16.  When designing databases, I like to create layouts for each
of the main tables in all three views, since each offers features that
the others don't.  For instance, in Table view users can change the
width of fields and move fields around while still in Browse mode,
whereas in List view they'd have to enter Layout mode to do the same
thing.

The issue is basically that in my designs I create an area at the top
of the screen that provides navigation to the main tables along with
buttons for commonly referenced functions so the database becomes more
of a freestanding app than a program where people have to learn FM to
use it.  When clicking the List button, everything shifts 3 pixels,
which feels jerky.  To counteract that, I subtract three pixels from
the header area and shift everything left by the same distance to make
the transition smooth.  When clicking the Table button, everything
shifts 16 pixels.  If I subtract 16 pixels and move the elements that
much leftward, the header appears to stay in place when moving from
Form to Table -- that is, it's not jumpy, so less disconcerting for
users -- but it means having 16 pixels to spare to begin with, plus a
little extra space to give things room to breathe.  In Table view this
looks fine, but building in that much padding in Form view -- say, 20
pixels altogether -- means a lot of dead space relative to how other
elements are arranged at the top.

To keep the aesthetics, it would be better if I could just turn off
the arrow column, especially because it doesn't add much functionality
(even the right-click context menu is pretty slim) and it's not
necessary for letting users know which record they're on if field
frames are being shown when the record is active.  So it's strange
that the FM designers would add something that takes up so much room
and not offer a way to hide it.  But so far I haven't found the off
switch anywhere.

-J.

In article
<af3ca9c8-936a-407b-b6be-4836592b5eab@b7g2000prg.googlegroups.com>, jahn
<jahnbigbooty@yahoo.com> wrote:

> Hi, Harry -
> 
> The arrow column in Table view is new as of FM 10 (if I remember
> correctly).  List view loses three pixels on the left side; Table view
> loses 16.  When designing databases, I like to create layouts for each
> of the main tables in all three views, since each offers features that
> the others don't.  For instance, in Table view users can change the
> width of fields and move fields around while still in Browse mode,
> whereas in List view they'd have to enter Layout mode to do the same
> thing.
> 
> The issue is basically that in my designs I create an area at the top
> of the screen that provides navigation to the main tables along with
> buttons for commonly referenced functions so the database becomes more
> of a freestanding app than a program where people have to learn FM to
> use it.  When clicking the List button, everything shifts 3 pixels,
> which feels jerky.  To counteract that, I subtract three pixels from
> the header area and shift everything left by the same distance to make
> the transition smooth.  When clicking the Table button, everything
> shifts 16 pixels.  If I subtract 16 pixels and move the elements that
> much leftward, the header appears to stay in place when moving from
> Form to Table -- that is, it's not jumpy, so less disconcerting for
> users -- but it means having 16 pixels to spare to begin with, plus a
> little extra space to give things room to breathe.  In Table view this
> looks fine, but building in that much padding in Form view -- say, 20
> pixels altogether -- means a lot of dead space relative to how other
> elements are arranged at the top.
> 
> To keep the aesthetics, it would be better if I could just turn off
> the arrow column, especially because it doesn't add much functionality
> (even the right-click context menu is pretty slim) and it's not
> necessary for letting users know which record they're on if field
> frames are being shown when the record is active.  So it's strange
> that the FM designers would add something that takes up so much room
> and not offer a way to hide it.  But so far I haven't found the off
> switch anywhere.

I do the same sort of thing with custom navigation / tool bars in most of
my database systems, but thankfully I don't use Table View so shouldn't
run into the problem you've got.

On the plus side, 20 pixels on taody's high-res screens is pretty small
.... in the old days that used to almost be the full size of a desktop
icon.

I doubt you're going to be able to turn off the arrow ... at least not
without hacking FileMaker Pro itself.

Helpful Harry :o)

Yeah, I think you're right.  I redesigned the button bar to give extra
padding for table view.  It actually looks okay.  Looks pretty normal,
really.

I'm actually a big fan of Table view.  It gives users a list view in
which they can resize fields and rearrange them if they want to
compare data side by side.  In fact, I almost began to think this time
around that I should do away with List view and just have Form and
Table view, since the only thing Table view doesn't offer is layout
objects, which I use in limited quantities in List view anyway.  Just
my two cents.

Thanks for your input.

-J.

On 19/05/11 7:00 AM, jahn wrote:
> Yeah, I think you're right.  I redesigned the button bar to give extra
> padding for table view.  It actually looks okay.  Looks pretty normal,
> really.
>
> I'm actually a big fan of Table view.  It gives users a list view in
> which they can resize fields and rearrange them if they want to
> compare data side by side.  In fact, I almost began to think this time
> around that I should do away with List view and just have Form and
> Table view, since the only thing Table view doesn't offer is layout
> objects, which I use in limited quantities in List view anyway.  Just
> my two cents.
>
> Thanks for your input.
>
> -J.


table view also comes with sort on all columns, which works even if 
browse mode access to fields is removed. While FM 11 has right click 
List view field sort , it only works if browse mode field entry is 
defined ( allowing table view browse mode field entry is generally a way 
to introduce data mutation...; better as a review layout than an edit 
layout)

I didn't realize you could right-click to sort in List view now.
That's handy.

I give users full data-entry capabilities in Table view, and if there
are areas for concern re changes to data, I assign script triggers
that run the appropriate operation when exiting the field.  This is a
good way to create indexable fields in related tables too; no more
unstored calculations.  Although I should say I don't provide users
access to every field -- utilities, matchfields, etc. are kept out of
view.  But anything they have access to in Form view is available in
Table view too.  For users who are used to working with Excel, it
provides a familiar look.

-J.