In fp5 I had several text calculations that incorporated tab characters
and displayed nicely, but they're acting funny in fp7. Displayed in
browse mode, tab characters sometimes appear correct, sometimes as 444
(a string of three fours) and sometimes as 000 (a string of three
zeros).

What's more, I can get all three results on the same layout using the
same field duplicated three times, so that even though the formatting
and everything else is exactly the same, the display result is tab in
one field, 444 in another and 000 in the third.

I've searched this group all the way back to 2000 and tried everything
that's been written about inserting tab characters into calculations,
so let me eliminate a few solutions:

1. Tab characters pasted into calculations from word processors do in
fact appear to be tab characters, but only in the define fields options
dialog. The actual calculated result usually appears as 444 or 000.

2. I've tried referencing a global text field that contains a tab
character in my calculations, but get the same result as with the tab
pasted into the define fields options dialog: it sometimes returns a
tab, sometimes 444 and sometimes 000.

3. Using "/t" in the calculation just returns /t as a result.

4. The issue exists in three separate files, none of which are
related, two of which have been made from scratch in FP7, one that was
converted from FP6, and none of which have ever crashed -- so it's not
a question of file corruption.

I find this problem vexing. Any suggestions? Is anyone else
experiencing it? Your combined wisdom would be greatly appreciated.

FYI, I'm using FMP 7.0v3 on Mac OS 10.3.9.

Thanks in advance.
-S.

In article <1119326358.271678.317090 (AT) g47g2000cwa (DOT) googlegroups.com>,
"Sug" <adam.sugerman (AT) gmail (DOT) com> wrote:

No one else seems to have replied to this one and I can see why. I
can't see any reason why a tab character would change into a string of
digits. The only things I can think of are:

- you're really inserting the digits at some place (perhaps
an incorrect field) or perhaps a Substitute command is
replacing them

- you've got the field using some strange formatting options
peculiar to FileMaker 7

- the field isn't a Text field

- the datbase file or FileMaker application itself is
becoming corrupt (which doesn't have to be because the
file has crashed, it could be the hard drive itself is
having problems).

The best way to insert a tab is to use a Global field that has a tab
typed / pasted into it - the "/t" tab substitute isn't a funtion of
FileMaker, so won't work at all.



Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)

Hi, Harry -

Thanks for taking a shot at this, because we've cracked it. I began
this reply by listing why each of your solutions wasn't correct, but
when I was addressing your mention of strange formatting options, it
suddenly occurred to me, what if it's a fill character? If that were
the case, each tab would display with exactly the number of fill
characters that fit into the space, which in this situation happened to
be three.

Sure enough, the fill character for each tab was set to 4 on one of the
fields and 0 on another. I can't believe I spent so many hours trying
to crack this.

But the real question is, why would three fields, each the duplicate of
the other (as in command-D; as in, option-drag; as in, never accessed
the text formatting dialog, let alone the _tab_ dialog three levels
down), suddenly set all the tab stops to 0 or 4? Doesn't make sense.
Is there a key combination I inadvertently pressed that sets tab fill
characters? Seems unlikely.

Nonetheless, I'm hugely relieved to have this solved. It was a real
time-burner.

Thanks again for all your help.

Best,
-Sug

In article <1119497230.203934.270590 (AT) z14g2000cwz (DOT) googlegroups.com>,
"Sug" <adam.sugerman (AT) gmail (DOT) com> wrote:

It's always the simplest answer that's over-looked. I probably wouldn't
have thought of looking at the fill character either. At least you've
now solved the problem. )

I doubt there's a keypress that would auto-set a field to use a tab
fill character to "4" or "0". Although it is possible when formatting
the field yourself to press the wrong key by accident (eg. perhaps you
wanted a hyphen as the fill character at some stage and hit the 0
instead).

It is also possible to set field format defaults by making sure you
haven't got anything selected and then changing the format options in
the menus or the side-toolbar. After doing that, any new field or text
added to a layout (not duplicate or copy / paste) will automatically
get that new default formatting. For example, click on 'nothing',
change the fill colour to yellow, then add a field or text and it will
be filled yellow.

Of course, when you duplicate or copy / paste a field it will also
duplicate any field formatting that the original field has.



Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)

If I'd ever ventured as far as the tab formatting dialog when working
on these fields, I'd definitely have looked in that area for a clue,
but as I mentioned above, these changes in the fill character came
about when I simply duplicated the field, without changing formatting
or any other settings.

However, I'm not entirely surprised. I'm finding FileMaker 7 to be the
buggiest commercial software I've ever used, with constant erratic
behavior when working in layout mode, manipulating graphics, altering
part sizes, etc. I've been developing in FileMaker since version 3 and
the current iteration just leaves a black cloud hanging over me every
time I have to work in it. It used to be such a reliable application.
To me it just feels like one big mess. Can't believe they sent this
one into the world without getting more of the kinks out.

Thanks again for your help.

-S.