Eliminate tags from merge?

[LaRetta]

Hello Forum!

I've been using custom functions for few years now (gleaned from Topic #120434) in merge letters. When we create a letter with merge fields, we always handle it like this ...

Dear <> or even Dear <>

If I can guarantee there will be no other green colors in the text (standard black-text letter), can I instead replace the merge with something like this:

Dear [color:green]FirstName

Of course we want that style removed in the final letter but, when a path is long, using merge fields can be quite confusing and messy. And if a User needs to remove an existing merge field, they sometimes leave pieces of it behind. Bummer.

Users have a series of buttons down the right side of page with the merge fields they can insert into letters. When clicked, it inserts the text (script parameter). I know that identifying the color of text is possible (I've read about it here on forums) but, although I find 1024 posts about coloring text, I can't even find ONE about identifying when it starts or ends so I can't even begin to start. Ideas appreciated!

LaRetta

[comment]

It's sort of possible, but I am not sure it's worthwhile. I would start with the output of GetAsSVG(). Taking your text:

If I can guarantee there will be no other green colors in the text (standard black-text letter), can I instead replace the merge with something like this:

Dear [color:green]FirstName

Of course we want that style removed in the final letter but, when a path is long, using merge fields can be quite confusing and messy. And if a User needs to remove an existing merge field, they sometimes leave pieces of it behind. Bummer.

GetAsSVG() returns:

If I can guarantee there will be no other green colors in the text (standard black-text letter), can I instead replace the merge with something like this:



Dear 

FirstName





Of course we want that style removed in the final letter but, when a path is long, using merge fields can be quite confusing and messy. And if a User needs to remove an existing merge field, they sometimes leave pieces of it behind. Bummer.

Observe the first section, the StyleList: it lists all the styles used in text, along with their starting and ending points IN THE ORIGINAL TEXT. So once you identify a style tagged as "color: #009999;", you will find the 'coordinates' of the colored expression immediately following.

And if a User needs to remove an existing merge field, they sometimes leave pieces of it behind. Bummer.

I am not at all sure you won't have similar problems using colors. It might be even worse, because you can never be sure where the actual styling begins and ends, with regard to preceding and following spaces (specially if user has edited around the mergefield). It's very easy to get a legacy of colored spaces (and nothing else) inside the text, or to find your mergefield surrounded by spaces after you extract it.

[LaRetta]

Wow. First I created the text field holding my test. Then created a calculation GetAsSVG(text) and I see it! Then created a calc Position ( text ; "FirstName" ; 1 ; 1 ) and see location of start (162).

So Middle ( text ; start ; end - start) and I will have it. I really like this stuff!!

Question before I begin ... Is Style#1 ALWAYS the color or should I pull the start/stop numbers after [color:green]color: or look for something else unique on that line? My thinking (and I'm sure you're ahead of me on this and have already decided it isn't worth trying but I can't help myself) is this:

If none of my merge fields have spaces AND if I use the same button which created the merge field to REMOVE it, then it can grab a space on each side when deleting it back out of the text. I see some of the traps of which you speak but not all of them yet. And of course a User can still mess it up but, well, I'm going to play with it. Merge letters and Contracts can get quite complex and difficult to read especially if I have a table occurrence which is quite long and messy. In truth, I was also considering just using a substitution table which would be:

First field: FirstName

Second field: <>

... and so forth, because even if I eliminate the chevrons it can still be long and ugly. Using buttons, I can substitute the displayed fields for the real ones.

Oh what fun!! Thank you so much, Michael! :laugh2:

Edited April 22, 2008 by Guest
added half sentence

[LaRetta]

Wooops! I answered my own question when I added a second field with color. Hmmm, this will take some thinking to convert the numbers into segments which will be identified by the CF. YAY!

Update: If I always use the same color, I can look for color: #008000!!

Edited April 22, 2008 by Guest
Added update

[comment]

Is Style#1 ALWAYS the color

No. It reads the text from start to end and creates a new style every time it encounters a change in text styling. So if bold text comes before colored text, it might look like:

if I use the same button which created the merge field to REMOVE it, then it can grab a space on each side when deleting it back out of the text

That's where the fun begins - because you don't know what user has done. For example:

"... your and [color:green]SpouseName's family...

and I suppose it can get much worse. If you ask me, I'd rather stay with the chevrons.

[LaRetta]

If you ask me, I'd rather stay with the chevrons.

You were right and the dang color was sometimes difficult to remove. However, I still think it is very ugly and distracting to have the merge fields look like:

<> or

<> and so forth

Even when we try to name our fields short and clear names, it can be difficult to decypher. And the double chevron and double colon add to the mess. I wanted it to always be simple so I've compromised. I use a substitution table. If you can see ways to shorten this concept, I would surely appreciate it. The reason I don't originally use a single chevron (and use a tilde) is because of the way I use a script in the text field. I suppose I could change the CF (or eliminate it since I'm using script?).

When you compare the first white text field with the second, I think it's easy to see why it might be worth implementing a standardized merge system which is simple for users to read and worth with. It's worth it in my book (especially if I can make it elegant). To a User, it's worth it. To a Developer? No. But because it is YES to the User, it should be yes to the Developer. I would rather take a few more minutes of my time and provide a cleaner solution.

Overview:

• Merge fields appear as ~FirstName~ etc (never spaces in merge fields).
• Via script, global is set with first merge field which is related to Substitution table.
• Script then replaces the merge field with the full merge path from the substitution table.
• It keeps looping and replacing until there are no more tilde left.
• The FINAL field converts the merge fields into merged text.

Improvements, suggestions or alternate approaches greatly appreciated. BTW, I still loved finding out about SVG() and identifying colors and I'm sure I'll use that knowledge in many other places (I took the time to climb in bed with it so it'll stick with me now). :smile2:

Merge_Alternate.zip

Edited April 23, 2008 by Guest
Corrected typo

[mr_vodka]

However, I still think it is very ugly and distracting to have the merge fields look like:

<> or

<> and so forth

So superficial.... :

[comment]

I am not up to getting into implementation issues right now, but on the presentation side:

1. I'd go with double chevrons, simply because it has become the standard.

2. I would certainly use easy-to-understand codes instead of real field names*.

3. You could still colorize the placeholders - provided users are not allowed to use colors in their own text, or at least not the specific color chosen for this.

4. I would try to give users the opportunity to preview the text with merged data from any chosen record.

---

Off topic, but IMHO real field names could be easier on the eye too, no? I often wonder who benefits from shortening names to cryptic codes like "st_Dte_Owed". Is that a date field? Great, so you have saved an "a". And what dividends does this saving bring?

[LaRetta]

Thank you for the ideas. I'm going to remove the demo and work it up quite a bit more. I ended up 'horsing' it through just to finish it but I'm not pleased with it. I agree field names should be as simple as possible but with attempting to keep the field names short (so they can show in dialogs which won't expand) and still making them meaningful, we Developers sometimes begin shortening things which are consistent (throughout a design), ie, dt for date etc. We are caught between a rock and a brick here and the answers simply aren't always simple.

I'll revisit this post once I have something better to present. Thank you!

One final question, if I may?

I'm currently using a script which loops and only always looks for the first occurrence of the tilde. Because it changes the tilde and data inside, I only need this one search and it exits the loop when no tilde are found.

A recursive calculation loops through a field of text as well. Since you suggested that a User be able to preview any record then this suggests (to me) that a recursive calculation should be used for it all and ditch the script. So, can a recursive calculation do as much as a script in a process such as this? If so, then the preview will be dynamic for every record.

LaRetta

[comment]

this suggests (to me) that a recursive calculation should be used for it all and ditch the script. So, can a recursive calculation do as much as a script in a process such as this?

Possibly - not necessarily. Obviously, a calculation cannot CREATE the merged records - if that's what your script does. OTOH, a custom function could highlight the merged variables for the preview - something that you probably wouldn't want in the final output.

But yes, in practical terms, if you go for the preview feature then it makes sense to leave all the substitutions to a custom function*. This can also have a parameter for altered behavior (e.g. do/don't highlight), so you could use the same CF for the preview and for the final output. I think that would be best, since at least the substitution logic would be all at a single location - even if the merge logic needs to reside in a script.

(*)The above applies to a "live" preview. You could of course stay entirely within scripting, and provide a scripted preview "on-demand".

keep the field names short (so they can show in dialogs which won't expand)

Oh, that. You're right, no simple answer for that one.

[LaRetta]

I think I'll still need a script because, well, I can't think of any other way to relate a single word in a text field to the substitution table (for isolation to grab the associated long path) unless I pull the word out and plop it into a global. That text multiline was my first attempt to relate them until I realized it was still ONE main record so simply wouldn't work on any following words. I should have removed it from the demo.

...so you could use the same CF for the preview and for the final output. I think that would be best, since at least the substitution logic would be all at a single location - even if the merge logic needs to reside in a script.

I keep thinking the substitution can be handled by CF too now, but again I wonder how a CF would handle the issue in my first paragraph. Is there any other way of relating words within a text field to multiple related records? When wanting to pull the related long path, it doesn't know which I want. I can't envision how a calculation alone (even a recursive one) could handle it. [color:green]Scripting both substitution AND merge might be necessary(?)

This will be wonderful to work through; I'll learn a lot from it!! Much appreciated, Michael!!

Edited April 24, 2008 by Guest
Added green

[comment]

If I understand the question correctly: the custom function needs to receive the entire substitution table through its parameters. If it's a real FM table, then you would have a 'x' relationship to it, and call your CF as:

CF ( ... ; List ( Substitutions::Code ) ; List ( Substitutions::FieldName ) ; ... )