How to format output data??

[Karen1958]

Can't figure out how to get a calculation (or a script step, I'm not choosy here) to take the data I put into a date field as (7/29) and output it as (Friday, July 29th).

[LaRetta]

Hi Karen

If this is just to display on a report (or such) you can easily specify it's format (for display) through its field properties. Right-click the date field, select 'Date Format' and, using the date selections in the center, format as you wish. As you change these settings, watch the full date display below - it will show you exactly what is happening as you change it.

BUT ... if you wish to actually change the data that will not work, of course. So when you say script I wonder what you want this field for. Because you would need to create a text field to hold the date as actual data formatted in this way or if you mean export by 'output.' If not just for display, we'll need more information. And it would also help to fill in your OS and FM versions for us.

LaRetta

[Karen1958]

Hi LaRetta,

I did give my OS and FM versions when I posted but for some reason it didn't display -(

FMP5 and XP

Yeah, this isn't just for display, or I'd have solved it long ago. The script outputs email and uses several calculation fields.

Any ideas?

[LaRetta]

Try something like this:

DayName(date) & ", " & MonthName(date) & " " &

Case(

Day(date) = 1 or Day(date) = 21 or Day(date) = 31; Day(date) & "st";

Day(date) = 2 or Day(date) = 22; Day(date) & "nd";

Day(date) = 3 or Day(date) = 23; Day(date) & "rd";

Day(date) & "th"

)

Vs. 7 is much nicer because one can use Let() to specify the Day as a variable which makes it easier to write, shorter and saves evaluations. I expect the calc masters to come along and sweeten this up further for us. I could probably improve this a bit more myself (but not to their level); however it's almost 3 AM here and I'm going brain-dead.

LaRetta

[-Queue-]

Well, I'm not sure how much sweeter it is, but

Case( not IsEmpty(date),

DayName(date) & ", " & MonthName(date) & " " & Day(date) &

Case(

PatternCount( " 1 21 31 ", " " & Day(date) & " " ), "st",

PatternCount( " 2 22 ", " " & Day(date) & " "), "nd",

PatternCount( " 3 23 ", " " & Day(date) & " " ), "rd",

"th" ) )

[LaRetta]

YOUZA! Much sweeter (and faster) and taught me something to boot! Thank you, JT!!

AND ... it protects from an empty date field. I should have caught that.

Update: Drat, my embarrassed emoticon is gone. Not sure I can live without 'em - I use him so darned much and I liked that little guy!

Edited July 29, 2005 by Guest

[-Queue-]

:blush:

[LaRetta]

Smarty-pants!

I found out there are two IDENTICAL blushies in 'More Smilies.' Stephen's testing us ... and I failed!! Yep ... feelin' spunky today. :yep:

[Karen1958]

Thanks, y'all! I will try those ideas.

[LaRetta]

Just another fun idea, JT ... and a bit more efficient?

Let(

[

d = Right ( Day ( date ) ; 1 ) ;

mod = If ( d < 4 ; d ; 0 )

]

; DayName ( date ) & ", " & MonthName ( date ) & " " & Day ( date ) &

Choose ( mod ; "th" ; "st" ; "nd" ; "rd" )

)

(couldn't sleep) ... :crazy:

[comment]

1. What do you get when Day ( date ) = 12?

2. D

[LaRetta]

Oh Michael, above solution just came to me in a flash while asleep.

Test, LaRetta, test.

I remember that thread TOO well - it's in my Puzzles folder and I've studied it many times!!! Above calc worked on a BUNCH of dates I tested (12 OBVIOUSLY not being one of them). Thanks for more goodies to play with! One knows they need help when they take their whiteboard to bed with them. JT's gonna have fun with me now. I don't suppose we can just delete me between you and JT, do you? That would be quite tempting.

LaRetta (sneaking back to bed)

[LaRetta]

Two quick questions if I may, Michael?

1) You have the concatenation before the Let[]. It seemed to make more sense within the final calculation (from a readability and logic standpoint). Many times (?) a calculation can be written either way and I can't help but wonder. If within the Let[], is it less effecient because Let[] has to consider it also?

2) I never attempt to use a function name within a calculation because of the confusion on what is meant. And FM won't let a function name be used as a field name so I'm safe there. Sometimes to keep it short, I've broken this 'rule' with variables, justifying my transgession by thinking I've used all small letters so I know the difference. And I've wanted to keep it very short. Yours is more descriptive (but longer) using exception instead of ex. Let[] doesn't seem to care; it's a variable after all. Should I care? Which is more important: Keep the variable name short, make it understandable or not use a function name.

I cringed when I used mod instead of modified.

Thank you!

LaRetta

[comment]

I don't think it matters from an efficiency POV. I believe (hope) that Let() works backwards, i.e. when it encounters a variable, it looks it up. So it's a matter of personal preference. The way I see this, the "final calculation" is right up at the beginning. Only the suffix has some complexity, so I use Let() to returns the suffix alone.

You shouldn't regard the often-used structure of

Let ( [

variable = something ;

...

] ;

calculation

)

as the only model available. Let() can be just as well used locally, even cascaded, e.g.

Let ( [

a = 2 ;

b = Let ( [ b1 = 3 ; b2 = 4 ] ; b1 * b2 ) ;

c = 5

] ;

a * b - c

)

Using variable names that are also function names is allowed, but IMHO bad practice. I try to follow the same conventions that Filemaker follows in naming function parameters, i.e. "parameter", or "functionParameter".

One thing that should definitely be avoided in naming variables are existing field names. That can be disastrous: say you have a field called "Name", and you have a calc that uses

Let ( name = something, etc.

Now if you delete the field Name, your calc will be utterly destroyed.

[LaRetta]

:o

The cascading logic and visualization of looking up sent me on a run, reviewing over 150 (great) calculations I've collected from various forums. I rearranged and re-wrote them all on my whiteboard.

Today is my birthday! My gift to myself will be reviewing and reworking as many calcs in my solution as I can fit in! Absolutely nothing I'd rather do! Thank you, Michael!!

Oh. And I have 5 or 6 calcs in which I need to change variable names.

LaRetta

Edited August 2, 2005 by Guest

[Ender]

Hi comment, LaRetta,

One thing that should definitely be avoided in naming variables are existing field names. That can be disastrous: say you have a field called "Name", and you have a calc that uses

Let ( name = something, etc.

Now if you delete the field Name, your calc will be utterly destroyed.

I'm not so sure about this. I've seen Let() used to overload a variable name to simplify things, like:

Say there's a number field "n", and a calc:

MyCalc (calculation, number result) =

let(

n = n*n;

n

)

I suppose I've seen this practice mostly in custom functions, but I don't see any pitfall with using this in regular calcs. If the field name "n" changes to "x", it changes in all places, including in the Let(). If you try to delete field "n", it tells you you can't because it's used somewhere.

Personally, I probably would'nt do this in a regular calc because it creates a bit of confusion as to which things are local to the Let() and which are external. Even though FileMaker knows what the scope of each variable is, I might forget.

Oh, Happy B-Day LaRetta! I hope you enjoy your birthday present. :o

[Ender]

I suppose I've seen this practice mostly in custom functions, but I don't see any pitfall with using this in regular calcs.

Clarification: in custom functions this overloading would be done with the parameter names, not field names.

[comment]

I'm not so sure about this.

In the attached file, try deleting the field Name.

(To clarify, I wasn't speaking about custom functions).

Untitled.fp7.zip

[Ender]

Ah, so when not used as the source for the variable (as in my example,) FileMaker loses the Let()'s variable if that variable happens to be a field name, and that field is deleted. A fine reason to avoid using field names as Let() variables.

It makes me think that the operation of deleting a field should recognize that variables declared in a Let() statement should be left alone. Other things recognize the scope of these variables correctly.

Interestingly, if you add a field to the table with the same name as a variable in a Let() statement, then delete it, FileMaker correctly leaves the Let() variables alone. But if you enter the calc after creating such a field, it binds it somehow to that new field and that delete problem will happen. The reason I'm pondering this so much is that I'd be concerned not so much about creating a variable with the same name as an existing field (the existing fields are easy to see,) but about the possibility of creating a field that happens to have the same name as a Let() variable, then having this unintended deletion problem later.

:qwery:

Edited August 2, 2005 by Guest

[comment]

I don't have a solution to offer, only a warning. I've been burned by this a couple of times, so beware.