TextStyleAdd ( "Help!" ; perplexed)

[Wickerman]

Okay, this is the first time I've had occasion to use the Calculation engine to format a field for display, so I'd appreciate a critique here.

1) I have a situation where I have a field that may or may not have data in it. If it does, I want the layout to display a little label ("Laboratory") and then on the next line, below it, the name of the lab (Grants::Laboratory). If it's empty, I don't want it to display anything at all. So I have

Case ( IsEmpty ( Grants::Laboratory ) ; "" ; "Laboratory" & ¶ & Grants::Laboratory )

okay. this works.

2) I would like to format the name of the Laboratory so that it is distinct from the label. So at the end of the calc I try this:

"Laboratory" & ¶ & TextStyleAdd ( Grants::Laboratory ; Bold ) )

okay. that works.

3) So how about a font size?

TextStyleAdd ( Grants::Laboratory ; Bold + 14 ) )

okay . . . NOT so good. When I look at the result, now the Lab name is tiny! Smaller than the 11pt formatting I have applied to the marge field on the layout -- the "Laboratory" label text displays as before, but the formatted text is still bold but now looks like 7 pt.

Is my formatting of the merge field interfering somehow? I thought the Calc function would supersede any previous formatting in the specified areas. No?

4) What's even worse, when I try to include a FONT name in the TextStyleAdd expression, for instance:

TextStyleAdd ( Grants::Laboratory ; Bold + Verdana ) )

. . . Filemaker rejects the Calc Save, complaining "The specified field cannot be found". Huh?

WHen I try putting the font name in "quotes" -- it allows it but the display format is not affected.

I have the Calc result set to Text, and the result is "Unstored".

What am I missing here?

[Raybaudi]

TextStyleAdd ( ) adds ... a style.

To change the size you'll need TextSize ( ).

You could use both, for example:

TextSize ( TextStyleAdd ( Grants::Laboratory ; Bold ) ; 14 )

[LaRetta]

If this is for display, why not just create a merge field as (entering both label and field within same text box:

Laboratory

<<Grants::LaboratoryText>>

Attach Object name to it such as Grants. Then attach conditional format to that merge as:

IsEmpty ( GetValue ( GetLayoutObjectAttribute ( "grants" ; "Content" ) ; 2 ) ) see below instead

And specify 'more formatting' and font size custom 500. The merge will disappear if the field is empty. There may be other ways as well. I dislike creating calculations unless really necessary.

ADDED: In fact, just IsEmpty ( Grants::LaboratoryText )

I've been getting to know GetLayoutObjectAttribute() on biblical level and I see using it everywhere I look.

[Raybaudi]

Where did you get LaboratoryText ? :laugh:

[LaRetta]

LOL, I got it from my ever-expanding incredibly strange mind and fingers who were doing three things at once in too many windows. I probably was also allowing drag n drop, ha hahhh!!!!

I appear to be on a slightly off but highly fun day. Thank goodness folks are cleaning up behind me. I usually don't run amok. :chili:

[Wickerman]

Raybaudi -- thanks for pointing out the error in functions -- I had seen an example and thought it combined fonts and styles and sizes all in the same expression. duh!

LaRetta I'm having a little trouble seeing through the erasure here --

1) So, I format both the 'Laboratory' label and the Grants:Laboratory expressions in a single text box as I want them (with the Lab name larger and maybe in a different font from the littler label). Then I apply conditional formatting to the whole text box that says "If Grants:Laboratory is empty" do . . . what? display it in a txt color that matches the background? I don't understand how the emptiness of the *field* makes the hard-typed text label disappear altogether?

2) I don't understand "font size custom 500" -- is it that the font size is so large that it effectively disappears because we only see the empty corner of the display? (Okay, if so then that answers Q1) Clever! Are there any strange effects that can result from using this sort of "trick"? Like if someone tried to print out the layout on paper would they get a bunch of extra pages? (Not that printing a data entry layout is a good idea).

3) Let's say I was doing this sort of thing for an actual paper report layout -- where I wanted labels to preface fields with data in them, but no labels for fields that were empty. Would my approach of producing a conditional text block using the calculation engine be the best approach? I've never done this sort of thing before, but need to now. Do developers typically make a conditional utility field for each text field and then, what -- concatenate them all? Or a bunch of sliding text boxes on the layout? (which seems like a nightmare).

Other approaches?

[comment]

Before conditional formatting, you had to use a calculation field for any layout element that you wanted to change based on data. This is not the optimal approach, because calculation fields work on the data level - and they are unnecessarily cluttering up your data structure when you need them only to make a layout prettier.

[LaRetta]

There are many times that we want a label (or any text) to disappear depending upon a condition. I've used it to only show a 'header line' of fields in on pages other than 1 (in report preview, for example). But I hide labels all the time on forms and use conditional formatting extensively.

So let's walk through your questions:

1) So, I format both the 'Laboratory' label and the Grants:Laboratory expressions in a single text box as I want them (with the Lab name larger and maybe in a different font from the littler label). Then I apply conditional formatting to the whole text box correct

that says "If Grants:Laboratory is empty" do . . . what? apply your formats specified below in the lower half of the conditional formatting dialog box.

display it in a txt color that matches the background? No, by setting the font to size 500, the entire merge field will disappear because it will be 'too big for your computer to see.' LOL>. You can also set the color to match the background but on different platforms/versions and through citrix and such, you can sometimes see a faint 'ghost' of the field. But if you use large font it disappears completely.

2) I don't understand "font size custom 500" -- see #1 :^)

3) Let's say I was doing this sort of thing for an actual paper report layout -- where I wanted labels to preface fields with data in them, but no labels for fields that were empty. Would my approach of producing a conditional text block using the calculation engine be the best approach? If it is important to hide the labels then yes. It only takes a second to do 20 of them and you usually would not have that many labels on a report.

Other approaches? With FileMaker, always. But conditional formatting uses the least resources. And resource-efficiency is always top priority. The time it takes the Developer happens only once but Users will suffer with slow system every day of their lives over and over and over. That is why we get paid the big bucks ... being willing to work towards perfection.

added part in red.

Edited January 26, 2012 by LaRetta

[Wickerman]

3) Let's say I was doing this sort of thing for an actual paper report layout -- where I wanted labels to preface fields with data in them, but no labels for fields that were empty. Would my approach of producing a conditional text block using the calculation engine be the best approach? If it is important to hide the labels then yes. It only takes a second to do 20 of them and you usually would not have that many labels on a report.

Thanks so much -- this sort of commentary is enormously helpful because it's not just addressing this instance but growing my general understanding so I can apply it everywhere.

To clarify just a bit more -- in the reply to #3 you are confirming that the concatenation of several text blocks based on a calculation field using appropriate conditions *is* the best / most reasonable approach to creating print reports without the superfluous labels, right?

In terms of resource efficiency, would these calculation fields be only mildly burdensome to the system since they are not appearing on the data-entry layouts all the time, but only when called upon to produce the needed calculations for the occasional print out? (The calculation engine is only engaged "when needed" - right? So if Calcs are used on a data entry layout, they do work every time you move to a new record -- while print-previews are engaged much less frequently?)

[LaRetta]

... you are confirming that the concatenation of several text blocks based on a calculation field using appropriate conditions *is* the best / most reasonable approach to creating print reports without the superfluous labels, right?

Yes. Usually. It would be used in form mode or list mode when there are multiple fields in the body part. If you attempt to place this text block across a header/body, it will fail (working only on the first record). So in one-row lists, I use merge variables for conditional column labels instead but the concept is the same.

In terms of resource efficiency, would these calculation fields be only mildly burdensome to the system

I would say that they would be much less burdensome but they too have some cost. As with everything in a solution, the need should be justified or worthy of the resource expense. Calculation fields are the absolute last thing I want to add to a solution.

Keep in mind that there are many brains more knowledgeable than mine and maybe some of them will provide specific examples of how conditional formatting is processed when served. I am not entirely clear on under-the-hood dynamics on them. I do know that calculations fetch ALL the fields in a table and not just fields being displayed (and all of that record's related records' fields if displayed in portal) and, because of dependencies (calculations referencing other calculations or related records etc), calculations are heavy-hitters. As Michael says, they work at the data layer. Conditional formatting works only at the layout level. I hope I explained this satisfactorily - it has not been the most efficient day for my mind and fingers.

Added sentence

Edited January 27, 2012 by LaRetta

[LaRetta]

"of several text blocks based on a calculation field using appropriate conditions *is* the best / most reasonable approach to creating print reports without the superfluous labels, right?"

In case I was unclear on understanding you or in case you were unclear on understanding me, the answer is ... conditional formatting is always best choice unless there is need for the 'calculation' in multiple layouts or other tables, for export - things required at the data layer. Conditional formatting is always the first tool I consider for visual aspects (and to also pass variables).

[Wickerman]

THanks, LaRetta for these elaborations on the theme. Very helpful.