DB.addHandler and alternatives

[Varsuuk]

[SOLVED]

First off, if DB.addHandler in a lua script associated with a windowless is best way, I will be happy as it puts it all in one place.

But I was wondering because I have seen calls to addHandler that took a wildcard expanded list of args so that the handler routine basically call "update your data" on all the "related" fields - whether they need updating or not if any of their, let's say 6 "trigger" fields are updated.

I thought perhaps to just register a handler for the changing of a mod value on each of the 6 attires separately. But I wondered if there is a scaling issue and if one might cause poor performance by having many handlers when can do with less at the cost of "waster work" when called.

The initial way I did it before I realized handlers could be neater was to have the trigger control have this script field:

					<anchored to="label_strength" />
					<script>
						function onValueChanged()
							window.adjusted_str_score.updateValue();
						end
					</script>

And the recipient field (in same sheetdata are) have:

				<script>
					function onInit()
						updateValue(); 
					end
					
					function updateValue()
						setValue(window.strength_base.getValue() + window.str_base_manual_mod.getValue());
					end
				</script>

This works, as I type in the manual modifications field, the total of auto and manual mods updates in real time. None of the other attributes ones do, of course

But basically the same code is spread out among all 6 except for the control names being changed to protect the guilty. (bad Dragnet reference, carry on...)

1. Which would folks suggest is "better" more "elegant"?
2. Is there a reason to be careful of adding too many such handlers via DB.addHandler() individually vs grouping them?


Thanks folks!

(I'm glad that a lot of my questions now are about which way or is it safe/efficient to do it this way vs "I can't get this to work, how do I do it" - between my better understanding in being able to read existing rulesets and the wonderful* API page - I've been able to get what I need done each time if not the fastest when it is UI and when I typo restext instead of textres in half the controls and don't notice it - but I digress)

* = I REALLY would love a way to search on a function name and it return all API entries where it exist though, faster than my current check "reasonable" guesses then rest

[Moon Wizard]

It depends.

If you need a function to be called on data updates and you can't assume that the window will be open, then you will want to use the DB.addHandler method. As you presumed, these do build up in a large list, and the entire list needs to be compared with on every database node update to see if it matches any entry on the list. So, it may eventually impact performance if you went crazy with them, but I haven't seen any noticeable performance issues to date. Also, as for grouping, less rules are better than more rules, so I use wildcards whenever it makes sense.

If you just need to update another control within the same window (especially if it's not a database-linked control), then the onValueChanged method is probably better. It's only firing when the window is open.

Regards,
JPG

[Varsuuk]

[SOLVED]

Awesome advice, thank you.

I hadn't considered the trade off in light of the fact that sure, making one function handle 6 stats (db linked fields) may seem like it wastes time processing all 6 as if all were modified vs the single actually modified one - BUT if you added 6 simple methods on handler, anytime ANY field is modified the FG code walks the modifier list (it's not a hash lookup based on field path I guess, which of course is STILL a lookup that more entries affects) so that you are better off blobbing so every time the handler list gets called for any of N fields you have ever registered, that's 5 less to walk when one or all of them are not needed.