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.
The issues:
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 (tinderbox@eastgate.com) 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.
Thank you.
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.
Mateusz
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.