When you use merge fields, there is only 1 character that matters, in terms of formatting: the first caret < The rest can be as small as you want it won't affect the output. So put the styling you want on the first character and a smaller size to the remainder of the string.
@Cecile - is what I get-LOL.
This is the relevant layout.
What on earth am I doing wrong... And, BTW, when I changed the font on the first "<" from 12 to 11, it wrapped and made the field taller. A real nuisance when trying to get fields to 'fit' in a portal row!
Did you read my post about resizing?
Change the padding and it will stop being dynamic. You are forcing a font inside a box that is too small for the font size plus padding you set.
With respect to the caret trick, I am being told that it doesn’t work always in FM 19. I have to check for myself and do some testing but won’t have access to my computer before tomorrow pm
@cpking How many singers do you have to choose from when building your set list? This will determine the UI for selecting singers and adding their names to the set list.
Thanks, @bdbd, for the comment. The "original request" was
First, I appreciate any help I can get as this projecthas been evolving over two years and, as these kinds of projects to, has become more involved and complicated over that time. I'm not a programmer, but a sort of user nerd, so my inquisitive mind wants to learn, but sometimes simple concepts elude me. Feedback, both on the specific goal at hand as well as the project overall is always appreciated.
I believe this forum, and others like it, provide an opportunity for people (like me) to learn, but also for others (like contributors here) to both share ideas and methodologies. Several different members have posted comments which have lead to either new threads on a given topic, or enlightenment of a single issue uncovered in the overall thread. So while I understand your comment, and certainly @steverichter has gone above and beyond on his participation here, I also believe the community at large benefits from seeing this project as an example. I myself found this forum by searching for answers and landed here. So just like me, others may find this thread helpful when searching for answers to various questions and challenges. I thank you for your comment.
@steve_ssh, I meant to reply to this comment a few days ago. @steverichter steverichter has convinced me to create a TYPE table which would indicate the type of Singer (solo, duet, etc.) for the PERFORMANCE of a song. In this way, I will be able to increment a specific Singer's song count on a gig, but display in the set list the fact that it is a duet (for example)
I'm still working through the kinks as developing these new relationships by inserting the TYPE table has also broken some of my layouts that were previously based on different TOs.
All that said, it is interesting to see the solution develop.
Thank you. I have been watching the exchange between you and @steverichter , but have not chimed in because I felt that one more cook in the kitchen would actually hinder progress/understanding. I had a few comments that I was saving, should they seem appropriate at a later time.
I'll mention them now:
As far as structure and naming go:
I agree with renaming the table that was originally called some kind of "join" table to PERFORMANCES. Great move, IMO.
I also agree with the introduction of the table that sits between PERFORMANCES and SINGERS. I believe that it is what you have needed all along, but you managed to get by without it by adding complexity to the SINGER table (i.e. allowing a Singer record to have a status of multi/individual).
While I definitely like the introduction of that table between PERFORMANCES and SINGERS, I see it as a basic join table, and I question the practical value of bringing TYPE into the concept/name of that table. That said, I've been content to watch and see where that goes.
With this new table (PERFORMANCE_SINGER_JOIN), the SINGERS table can now lose the complexity of tracking duet/multiple statuses, and it could just become a simple table where each record represents exactly one unique singer. I really like that.
And, once the SINGER table has such simplicity, you are afforded the option of merging your SINGER table and you ACCOMPANIST table into a single TALENT table that holds both singers and accompanists, and some kind of additional field to differentiate between the two. I'm not saying that you must do that (though I probably would), but now it is actually an option available to you.
The only thing that has remained a question for me was where you and Steve were headed with handling the Set and Slot fields. My own sense is that those two fields belong where they presently are, i.e. in the PERFORMANCES table, but my interpretation of some of the above conversation let me to believe that there was thought of moving those fields into GIGS, or somewhere else, and that never made sense to me. So - that was another topic where I was just watching to see where things wound up, figuring that I might learn a thing or two, or just see that I had misunderstood some of the intentions.
Additionally:
With this new structure, I think you may find yourself weighing the option of using some slight denormalization to bring a list of singer names into a field stored in the PERFORMANCES table, so that single PERFORMANCE record could display who is performing on that performance, without having to reach through relationships to dynamically pull such a list when the UI is rendered.
is what I get-LOL.