my notes use subtitles showing values of a few key attributes. I have several key attributes which I fill whenever I create a new note since they are specific to that note. The number of key attributes exceed window for key attributes and I have to scroll down (just as an additional information). This is sort of a database for me.
Whenever I fill a key attribute which is used in a subtitle, Tinderbox changes focus to update the note. I have to click back into the right-hand side panel to continue filling the values.
I suspect this is a design choice but I would like to ask whether or not I can force the application to keep focus on the attributes. If not then perhaps there is a keyboard shortcut to go back to the key attribute panel?
When I reach the end of key attributes window (visible key attributes), I can hit Return to continue filling next values. However, the view does not follow the cursor and I have to manually scroll down to see what I am filling.
Is there any way I can make Tinderbox scroll to the values I am entering at that moment? It scrolls automatically when you just click on the attributes (without filling them) and move with cursor keys - it doesn’t when you fill the values and press enter. I can hit Escape to stop editing and then the scroll is followed again when I change to a different key attribute with cursor keys. It is just that one additional input you need to make when filling a lot of data becomes annoying, haha.
Side note for later readers. From v8.8.0 Key Attributes were superseded by Displayed Attributes. DA now do everything KA previously did. All KA-based system attributes were replaced by DA-based ones. however, if you acttions, template etc., make reference to KAs they should be revised to use DAs e.g. $KeyAttributes →$DisplayedAttributes.
The above begs the question which version of the app you are using. At time of writing v9.5.2b606 is the current public release of the application.
I can’t replicate this issue (using v9.5.2). In order to test your issue #1 can you please explain how the note’s subtitle (i.e. $Subtitle) is being set? Seeing to code used and knowing how it is applied will ensure we are testing the same scenario in the same way.
As to #2, that is better reported direct to Tech Support (firstname.lastname@example.org) as it is something your fellow users here can’t fix.
I use the demo version of 9.5.2 (b606). You are right, the naming convention I used in the first post is from an old demo version I used earlier (8.x something something). I set up the document there and then I opened it up in the new version. The translation went flawless and the question is still valid for Displayed Attributes.
Thanks. i’m still struggling to implement this as a test. Here’s what I have so far: subtitle-issue.tbx (156.9 KB)
But there are no Displayed Attributes specified and no test test date. Could you perhaps built out the above test with note(s) and data that replicate the issue. It’s not clear whether the problem is in an adornment or in notes places on the adornment. That said as the adornment’s action, essentially its OnAdd, re-sets the dropped notes $Xpos, any note added to the adornment is immediately moved off it.
There is a logic error with your linking code as note how my test note is linked to the ‘Prototypes’ container which isn’t meant. I’d probably not use the system attribute ‘Range’ for your purpose as it’s there for a different (geographical) function and you don’t want stray range info popping up by mistake. A Number-type ‘WeaponRage’ seems a better and more descriptive choice.
At this point, I generally find it better to build a test just using $MyName and $MyNumber, etc. So it’s easier to see what’s going on. I should add that I don’t think the number of Displayed Attributes has any bearing here.
Is your adornment supposed to have a prototype? It does so because the adornment’s rule sets one via $Prototype="Weapon Name";. However the prototype doesn’t make sene in the context of the adornment.
I’ve also tried some tests with the new update() operator. My hunch is that changes in the text pane aren’t triggering a full view refresh (and update() is working under the same assumption. That’s not silly as it might first seem when your think of when your map has 100s of notes: you don’t want everything updating all the time.
Whatever, when I edit Displayed Attributes, the focus doesn’t change at all and stays on the Displayed Attributes table.
I have tried to replicate the issue on your file and the focus is rock-solid on the edited Displayed Attributes. I have added to the prototype the aforementioned attributes to be Displayed Attributes and the focus is still there.
My adornment is large enough so that doesn’t happen. I just wanted to make my life easier and have new notes linked and positioned correctly. I believe I need to have the previous note selected when I press Return for the new note.
There is a logic error with your linking code as note how my test note is linked to the ‘Prototypes’ container which isn’t meant.
Thanks for the tip. Since that prototype is specifically made for the adornment and this type of notes, it does work well (so far). I don’t manually assign the prototype. But indeed, it may have cause issues in the future. It should probably has some function which checks whether or not the note is on the adornment and there exists previous notes on it - no links if both are false. EDIT: the first part should be easily doable just by moving it to the adornment’s action.
I’d probably not use the system attribute ‘Range’ for your purpose as it’s there for a different (geographical) function and you don’t want stray range info popping up by mistake. A Number-type ‘WeaponRage’ seems a better and more descriptive choice.
I wanted to create the “Range” attribute and it said it is taken. I checked it and it is of a number type which works for me. I understand specific functions use this specific attribute and there may be a conflict in the future. Noted, thank you.
Is your adornment supposed to have a prototype? It does so because the adornment’s rule sets one via $Prototype="Weapon Name"; . However the prototype doesn’t make sene in the context of the adornment.
No, it doesn’t. This is the leftover of my failed attempts of forcing the notes to have that prototype.
All in all, I will just start using your file as a playground since obviously I have put something in my, I shouldn’t have, haha. In some spare time, I will try to find the hidden catch I have in my file.
Thank you for taking the time to look at my case.
My recollection had been that manual edits to attributes used in Displayed Attributes caused the rule/edict to run, but this clearly doesn’t happen here. There is also no method, form the context of Displayed Attributes, to say “update this note in the view pane”. Anyway, I suspect re-drawing one note means re-drawing all of the (visible part of the) map. However, there is a way to prod a view re-draw: click on the label of the current tab:
Thank for tor additional information. However, my case it isn’t about making sure the subtitles are always top-notch updates. To be honest, all I wanted is to make sure I am able to rapidly fill multiple attributes (yes, I have to since they are note specific) without having to remove my hands from a keyboard. Changing the focus in my file prevented me from doing that and I am glad we came into conclusion that it is not the case. After all, I was playing on my first Tinderbox file, I tried a lot of things. Some breadcrumb functions are still here and there as you noted with setting a prototype for an adornment, haha.