I’ve just viewed the TB Meetup video hosted by Michael Becker on Sept 18 2021 (Blogging basics - lesson 1) and have created a similar workflow - looks pretty good.
The issue is that I decided to use the Person prototype, but with a user-defined badge, as opposed to sticking with the TB default ones.
I had no issue in creating the badge (CMD + 1, Appearance Inspector, Add Badge) - it worked fine. I did the same for a couple of others. However, I decided to change the first badge to something more appropriate, which I achieved following the same procedure. However, the result turned out quite strange:
In the inspector, the badge shows the REPLACED badge. However, in the prototype, the badge shows the FIRST badge that was created.
So a couple of things:
I have a prototype: pPerson which uses the defaults supplied (including the badge).
I have two other prototypes: pMale and pFemale that inherit values from pPerson.
The only difference between the two are their badges.
I tried the Reset in the attribute viewer, but no difference. I’m wondering if it’s some sort of caching issue that’s affecting the pMale prototype?
Certainly sounds like a caching issue, the edge case here being that you’ve changed the source artwork during an app session (i.e. whilst the doc and/or app is open).
If experimenting with badges, one approach to make things easier might be to give each badge variant a discrete name (‘person1’, ‘person2’, etc.) and experiment with look and feel. Once the artwork selection is correct, set the master prototype’s badge to the normal naming, e.g. ‘person’ close the app. Rename the desired badge variant to to 'person ’ (and delete others if not know needed. Reopen app/doc and all should be using the correct long-term name and associated badge artwork will be used.
Over time, experience has taught me that that last step of weeding temporary experimental values and then setting the original name to point to new artwork avoids hard to figure breakage down the line.
Pro tip. Once you’ve internalised the last point above, the wise person does all this testing in a demo file and and then simply takes the new artwork file(s), appropriately name, and use them in your main work document. Once a real work document has a fair amount of time put into it, using quick test TBX (that you throw away once the test is done) massively lessens the likelihood of chasing down the one or two notes that now has the wrong badge/shape/whatever. No one has to take this approach. To me me its en-lightened self-interest in getting to the correct en-point with less hassle/timer expended.
Thanks, Mark. Yes - I get the concepts and importance of testing in unfamiliar territory (it’s my “trade” as a Test Consultant), to avoid releasing untested code into the wild. Your solution to test first in a throwaway TBX file is spot on - it reduces variables.
In the meantime, there’s some investigation that needs to take place to locate and correct the badge problem. I guess I could reproduce it as a stand-alone TBX file and send to Eastgate for them to investigate.