Tinderbox Forum

Tinderbox Training Video 23 - Using code notes and caching variables with action code

Training Videos
#1

Tinderbox Training Video - Using code notes and caching variables with action code
Level Advanced
Published Date 1/12/20211
Tags Tinderbox, aTbRef, 4Cs of Knowledge Exchange, Code Notes, Action Code, Conditional Statements, Action
Video Length 13:13
Video URL https://youtu.be/yhCceOIAq2M
Example File TBX - L Using code notes and caching variables with action code.tbx (89.3 KB) ]
Revision 1
TBX Version 8.9
Instructor Michael Becker

In this lesson, I introduce you to the concepts of code notes and attribute value caching. Using code notes can help you managed (create, edit. and maintain) your action code. Using cached values that other notes draw on can increase the performance of our Tinderbox file since if done properly, Tinderbox will only need to perform a calculation once for a group notes rather than having each and every individual note perform a calculation for itself.

[TBX - L Using code notes and caching variables with action code (https://youtu.be/yhCceOIAq2M)

Reference Material

2 Likes
Mastering Tinderbox: Training Videos (Complete List)
#2

Everything looks super crispy in the video. You seem to have nailed down the aesthetics , video and sound quality !

#3

Thanks for the feedback. Yes, I played around with a bunch of settings last night. Glad to hear it worked.

#4

@satikusala Great video! And also really nice use-case for the task management checks.

Regarding the cached variables, I understand that the guard if($ColorYellow!=$Color) is there to set a note’s color only if the new color different from the current one. The thing I don’t understand is why use $ColorYellow!=$Color instead of "yellow"!=$Color.

Is it for speed, or is it a form of refactoring to make it easy to change what $ColorYellow means throughout the document? For example, to change the shade of yellow, or to define a “theme”?

#5

Ah, wonderful question! It is there for performance. If you just say $Color=“yellow” Tinderbox will draw the color yellow on all notes, regardless if it needs it or not. Redrawing the outline and map view takes processing time. So, if you put the if statement in there, if the color is already yellow it will skip the redraw step. To be honest, this insight is all @eastgate. My file was getting terribly slow and Mark showed me this trick a few weeks back. :slight_smile:

#6

Thanks Michael. I was asking about the (in-)equality testing ($ColorYellow!=$Color) not the assignment ($Color=$ColorYellow). I understand why avoiding unnecessary assignments to prevent redraws improves performance, but I was wondering what the gain was (if any) to check the values of $ColorYellow instead of the string "yellow" directly.

#7

It is all in the logic. If then then that else. So it reads like this, if color is not yellow, then don’t do anything. If it was the other way around, it would be if color is yellow, then do something. In this context I wanted the former. The color is already yellow; I don’t want it to do anything when the color is already yellow.

#8

I think @satikusala might have misunderstood your question.

You asked:

why use $ColorYellow!=$Color instead of "yellow"!=$Color ?

I think the point here is performance optimization. It takes a little work for Tinderbox to translate the string “yellow” into whatever color is “yellow” in the current color scheme. If you’re worried about performance, it’s easier to do this once and to store the result in $ColorYellow than to do it for each note in the document. So, you save a little time by avoiding the conversion.

Now, I doubt that’s really going to matter much, but these things do sometimes crop up with really large Tinderbox documents that are doing exceptionally complex things. Color conversions are pretty easy, but date conversions are common, too, and they can be trickier than you’d expect.

Your conjecture about refactoring is also perfectly sensible. You might, for example, want the specific color to be independent of color scheme. I’d use $ColorCaution and $ColorAlarm instead of $ColorYellow and $ColorRed, but this can make sense, too.

#9

Nice idea… :slight_smile:

#10

Thanks Mark, that makes a lot of sense and is indeed the sort of answer I was looking for.

Michael, no hard feelings. :slight_smile: