Field format help

[BigZilla]

I have a file [Mfr] that has 2 fields. I have one formatted as UPPER CASE and the other field formatted as Title Case.

I have a file [Cont] that has a portal from the [Mfr] file with the above two fields in it. They have also been formatted to UPPER CASE and Title Case respectively. My problem is the names in the fields from the portal are shown the way the data was entered into the filed in the [Mfr] file. So if one manufacturer was entered as FORD and the other as chrysler, that is just the way it is shown in the portal field even though the text formatting is set to UPPER CASE.

Is there a way to fix this so all names in this field are UPPER CASE?

Thanks for your help,

Bill

[mse]

1. Format YourField as required (e.g. Format --> Style --> UPPERCASE)

2. In a Startup Script to the file, add:

Set Field [YourField, YourField]

Next time you open the file, the field will be formatted properly.

[Lee Smith]

Text Formatting at the layout mode level, amounts to viewing your text format using smoke and mirrors. In other words, the actual text in the field is not changed, only how it is seen. You can change your text format in the portal to reflect how you want to view it, Layout Mode - Menu - Format - Text and then choose the UPPERCASE or Title Case from the pull down menu.

You can also do a replace on the field to change the field content to what you want. Menu - Records - Replace (Cmd = on a Mac) and use Replace by calculated result - Specify and then the proper function either Upper (text) or Proper (text).

HTH

Lee

[mse]

Yet another "instant" solution based on a ExitField script (the source is no more available).

Note: Field1&2 are stacked, see also the "Field Format"

P.S. Hoping not to have an ethical problem with it: it is too hot here to prepare a proprietary demo...

[Fitch]

The original question sounds strange to me. If you select the field in Layout mode and apply formatting, it should display the way you want. However, selecting text with the text tool in Browse mode will only apply formatting to that one record.

As Lee noted, this only affects the display of the data, the data itself is not changed. But that may be all you want in this case.

[mse]

That may happen if user "copy-paste" into the regular field (not the case of portal)

[Lee Smith]

Time for Bill to respond.

[BigZilla]

Ok, so I forgot a little piece of information. Man, you guys are so picky, it's like you just want to know everything.......

What I forget to tell is the two fields in the portal are Pop Up lists and the values come from the [Mfr] file.

Sorry about that but I'm learnin!

Bill

[-Queue-]

BigZilla said:

Ok, so I forgot a little piece of information. Man, you guys are so picky, it's like you just want to know everything.......

That and world domination are our two greatest goals.

What I forget to tell is the two fields in the portal are Pop Up lists and the values come from the [Mfr] file.

In California, we'd call it the Mfn file. Perhaps you're not that crude in WY?

[Fitch]

OK I just did a little test and here's the deal:

The popup will display as entered, but once the value has been selected from the list, the field in the portal will have the correct formatting. So you can either live with that, or...

Create a calc field in the related file that is Upper() or Proper() and then base the value list on that.

[Lee Smith]

We've come a long ways to get back to my original posts

[Fitch]

I don't agree, Lee. Nothing against your original posts, but this isn't the same thing. The popup list puts a different spin on it.

[Lee Smith]

Why, because it delays the formatting in the portal.

Lee

[Fitch]

I'm just saying that, although we're both offering solutions based on the Upper() and Proper() functions, the solutions aren't the same. I thought you were saying that the thread is repeating itself but it's not.

Your solution is good as far as it goes. But since we have an ongoing data-entry problem, it doesn't seem that practical to have to do a Replace over and over. And when would you do it? The data entry is presumably going on all the time. So at any given point, you could have a messy popup list.

I hit upon the idea of creating a calc field in the related file and basing the value list for the popup on that. IMO this solves the problem pretty neatly. Not only do you get a popup that always looks correct, but the value that is set into the field will be properly "cased." If this idea is mentioned elsewhere in this thread, please point me there, because I don't see it.

[Jake Sterling]

the simplest way to do this is to do a Replace on the field you want in upper case. If that field is "Mfr" then the calculation should be this:

[color:"green"] Upper(Mfr)

What this does is to actually replace all the letters in the Mfr field in each record with capital letters. When you change them by formatting them, FileMaker still remembers the way they were originally typed in.

You could also use this calculation as part of a script which would run on the individual records as they are created so that future records would be formatted properly.

Hope this helps. Be careful with the Replace command, You can really louse yourself up by replacing things wrong. I always back up my database before I try something new with it.

[Fitch]

OK, now we're repeating a little. Replace has the problem that I mentioned above.

But, Khasidi's idea of running a script as each record is created is new to this discussion. This will work if you tightly control the record-creation process with scripts.

[Lee Smith]

Hi Tom,

Good points all around. Thanks for pointing out the constant need to do a replace on the field. The calculation and a script at creation are good suggestion too. Somewhere in all of this should be a solution to Bill's problem.

If not, I have one last suggestion Bill. It called the ruler solution. Get a nice hard 12 inch ruler for close supervision, or 36 inch ruler (yard stick) for long distance, and smack the users right on there knuckles if they don't impute the information in correctly in the first place.

Lee

[-Queue-]

I second the sadistic solution. It's much easier (and possibly fun) to implement.