Ah-ha! Excellent point. You are approaching Black Belt OptoExpert status for your deft use of pointers and even pointer tables.
Now, you force me to point out a couple of limitations in our HMIs which I work around by, in this case, re-loading one string table (which is not-so-efficient, as you noticed).
I don't actually recall if the HMI was specified as groov, or if I just picked that because it's nifty and fun. Unfortunately, groov doesn't currently support pointers or timers. So, that forced my hand... lucky the copy was pretty fast.
Fortunately, the more mature product PAC Display is cool with pointers, at least, enough that your implementation would be lovely and faster as you mention!
I would love PAC Display (and the OptoScript compiler) even more they could do a double-derefence for us. In other words, if you could skip needed the pstButton_Labels pointer and just have PAC Display directly get the string from something like:
Even better if that 2 could also be a variable. Now were getting into some really crazy pointer stuff.
But I digress.
I should mention, though, the trade-offs we make in these kinds of choices. For example, here I avoided pointers because groov doesn't do pointers yet. But in another situation I'd make that same kind of trade-off on speed (if it's not too much of a hit) vs. "can the next guy understand it."
Let me explain that.
Obviously, you are perfectly content and happy to use pointers and pointer tables and that's excellent. Not everyone is so comfortable (especially on a Friday afternoon) and might get a headache trying to understand all that. We have many non-programmers who love our stuff because it's easy to program without any heavy-duty programming experience or special knowledge. They can do all their logic without ever using a pointer or a subroutine and they like it that way.
Let me give another example of a style/efficiency choice--a pet peeve of mine, actually. While in OptoScript, you could write code that looks like this, and it might even make sense to some people who think this way:
doOutsideLights = not (bDayTime);
I would much rather see this (or at least a comment explaining what that one line above is supposed to do):
if (IsVariableTrue( bDayTime )) then // if it's daytime, we don't need outside lights
TurnOff( doOutsideLights );
else // it's night time, let's turn on those outside lights
TurnOn( doOutsideLights );
Is the first way a little faster for the PAC to process? Probably. Does it matter with today's processor speeds, especially for a lighting application? Unlikely.
Is the second way easier for my brain to comprehend? Definitely. And I need to save as many of those CPU cycles as possible!
Anyway, thanks for pointing out the pointer thing. You make a pointedly good point. HAR! Okay, I'll stop now.