[Snard]

I apologize if this question has been asked before. I've been searching in the forums for an answer but could not find one.

In the original MobileSheets, there aren't many choices for the format of the song title. There is a single checkbox in Options that allows the custom field to be appended to the title. The custom field is appended only when it is non-blank, and is separated by a "-" and surrounded with [] characters. For example, for two songs, one with a custom field value and one without, the titles would look like this:

• Song Title 1
  
• Song Title 2 - [Custom value 2]
  

Now, with MobileSheetsPro, we have many more options to choose from: both the song title and the caption can be customized to include many possible fields with a variety of delimiters and surrounding characters. However, I can't find a way to suppress the delimiters and surrounding characters when the fields in question are blank. For example, if I configure the song title to be the same format as for MobileSheets, I would get the following titles for the previous example:

• Song Title 1 - []
  
• Song Title 2 - [Custom value 2]
  

Not all of my songs have a value in the custom field (in my case, I generally use this as a song number in a choral hymnal) so all of the songs with "- []" at the end look cluttered.

Is there a way to suppress the separating and/or surrounding characters when a particular field is blank, that I might have missed in the manual?

Thanks,
Mike

[Zubersoft]

At one point I was playing with the concept of tying together delimiters with the fields that follow them so that I could identify when they should or should not be shown. For example, if you had %TITLE% - %ARTIST% - %COMPOSER%, but artist and composer are not set for some songs, I would hide everything but title. If composer was set but not artist, I would show only the one dash. The reason I didn't try to move forward with this more advanced processing was concerns over how well it would perform, considering I would start having to validate and modify strings dynamically instead of doing a more straightforward replacement. I'm sure this was probably a needless concern though, as the string processing probably wouldn't be expensive enough to notice.

In order to provide support for what you are describing, I would need to have some basic rules. First, I would need to add a checkbox for "Hide Delimiters for Empty Fields" or something along those lines so that people have control over this behavior. Next, I would have to make an assumption that any characters following a valid keyword up until the next keyword with an empty value would be removed. Additionally, any characters following an empty field such as ), }, ], and > would be removed as well.

Thoughts?

Mike

[sciurius]

What about

%ARTIST: - ARTIST, %

where left of the colon is the key, and right of the colon the text to be added when the key is non-empty.

[itsme]

I would appreciate a solution for this topic. Until now I ended up in using no delimiters at all.
Omitting prefixes would be easy, brackets or the like surrounding fields could be difficult. Something like the proposal of Sciurius seems to be worth a try.

[Zubersoft]

Johan's solution would provide more flexibility, but would definitely increase the complexity of setting up the format fields. An interesting use of it would be to show a different field if one didn't exist, i.e. %ARTIST: -ARTIST, %COMPOSER%%

Having said that, I can't really think of too many situations where you would want to display something for a field if it didn't exist. It seems like you almost always would want the field and delimiter to be hidden. I'd like to keep it simpler if possible, but if there is a strong argument for providing conditional replacement values, I can go that direction.

[sciurius]

An interesting use of it would be to show a different field if one didn't exist, i.e. %ARTIST: -ARTIST, %COMPOSER%%

I'm not quite sure I understand the semantics of this construct.

My intention was:

If ARTIST has a value, substitute everything after the :, repeat. Probably I should have written

%ARTIST: - %ARTIST%, %

or, more formally,

%<field>:<text if defined>%

This would be fairly easy: on 1st pass, check if artist has a value, if so replace by everything after the colon. So it becomes

- %ARTIST%,

On second pass, there's no colon anymore so the field value can be substituted.

For an if-then-else functionality, we could do something like

%<field>:<text if defined>|<text if undefined>%

This looks simple, elegant, easy to implement, yet powerful.

[Zubersoft]

After studying what you just typed, I realize that it looks like you were intending to provide a mechanism to specify the delimiter between multiple values for artists. That is a fairly useful approach, although it definitely creates a little more work for me, as currently the values are cached with the comma delimiter in place, so I would have to split and rejoin them if something other than a comma is specified. As a side note, the first part should be %ARTISTS:, as the field is plural. I think I'm going to modify the syntax to this:

%ARTISTS: - ${VALUE}%

This makes it a little easier to parse and I have fewer keyword values I have to look for by using ${VALUE} as the place to insert the field value. Anything inside the braces but after VALUE is used as the delimiter between multiple values. If just ${VALUE} is specified, the default delimiter will be used, which is a comma followed by a space. A more complex example with a conditional field could then be:

%ARTISTS: - ${VALUE}|${COMPOSERS: - ${VALUE}}%

This would show artists if defined, otherwise composers are shown, If composers is not defined either, then nothing would be shown. Using ${ followed by either VALUE or another field makes it a little easier to identify the end of the statement.

I like your approach, but I still think it's more complicated than what most users would want to deal with. Most would probably be confused by it, especially those that do not have a strong tech background. I think I will support both approaches - the simple approach that tries to automatically eliminate delimiters with empty fields as well as the more powerful syntax that provides more control.

[sciurius]

Good suggestions. I fully agree that this should not become too hard or complex, it's just a title on a screen and not a part of a quality typeset document that has to withstand the ages .

[Zubersoft]

I need to get an option: if you have a format field such as %ARTIST% - %ALBUM%, and artist is blank, should I show just the album, or should I show the delimiter so that it's obvious the artist was blank? I doubt people would get confused if they only saw an album... but I just want to be sure.

[sciurius]

I have a lot of songs in my list that display with a leading dash because I didn't fill in the first of fields. I think that's correct behaviour.
AFAIC, everything outside of a %FIELD% is literal text, and should be treated that way. Trying to be smart will definitely backfire. It will be smart for some, and unsmart for others.

I proposed the %FIELD: ... % syntax just to avoid this.

[Zubersoft]

Yeah, I think you are correct. I'll stick with the current behavior and add support for the more advanced syntax for those who want to have more control.