That's pretty neat.
I haven't seen a single $ variable used as a merge variable before. FM Help recommends $$ vars, but doesn't say why.
They recommend $$ variables because these are global and persist until they are explictly cleared. $ variables are local to a script and only exist as long as the script that created them is running. So they will display data as long as the script that created them continues to run. If it ends the $ variables will be lost and the merge variable will no longer display the data.
Depending on the application, this can be useful. It is up to the developer to determine which one best meets the applications needs.
Hope this is helpful
Is the justification you wrote for the Help file recommending $$ merge variables something you've heard from FMI? I've never seen that made explicit. And it doesn't cover this situation since Frank isn't using a script to declare his $ merge variables but a Let() calc in conditional formatting.
I suspect it's just another case of FMI (engineers or manual writers) not anticipating how developers are going to do with the tools they give us.
Thanks, Frank. I like learning new stuff, especially when I have a real use for it.
What would be nice is if one could remove the blank columns when only the rightmost one or two checkboxes are selected.
So instead of the first column being $c (for Company) it would be $firstcolumn or $columnone, and the value would depend on a clever calculation involving the valuecount of your global displaying the check boxes. (Sorry, I don't have time to be that clever right now - but you did ask for suggestions. ;-)
Yes, Steve, I know what you mean about the blank vertical spaces.
On that demo I put each record variable in its own text object. That method makes the columns' position. static. If, on the other hand, they were all in a single text object, and if each variable's calc appended a tab character, that lets the second and third columns slide left when the first column is disabled. Something like...
tab = " " ;
$c = If(not $$c_on; ""; Members::Company & tab ) ;
$p = If(not $$p_on; ""; Members::Membership Type & tab) ;
$e = If(not $$e_on; ""; Members::email & tab )
The col headings would need a similar scheme.
Bruce and David,
I figure FMI recommends, not requires, global variables as merge variables because it will work reliably (as a new feature). As David suggests, the tools let us do so much more than the documentation suggests.
I recall reading (way back when?) somewhere (citation?) that local variables are not actually destroyed when a script ends, in some technical sense, but rather they persist -- no longer available to scripts. For me it was one of those interesting factoid that lived on without useful purpose. Someone who is versed in the hows and wherefores of memory stacks might shed light on this.
The inspiration for the dynamic column display came from a solution posted by Bruce Robertson called "summaryhilite.fp7". He used local variables to evaluate differently on each record in a list view.
If it ends the $ variables will be lost and the merge variable will no longer display the data.
We've been using $ merge variables for several years now and they work a treat. The $ merge variable value persists on the layout and still displays its value so they can be used to display many things from total page count of a report to complex calculations.
This is beneficial since redraw of a list begins on record one and calculates downward. The combination of this sequence/redraw is that it can aggregate, display its value in $ variable then move to the next record.
I should clarify further in reference to what Frank said about the $ variable value persisting ... $ merge variable persist on layouts because their value has died after display and nothing is forcing it to change again (script or conditional formatting recalculation).
I believe this is what FMI was talking about and not that a $variable value persists after scripts end but I will not attempt to speak for them. If script variables persist after script finishes, would we not see them in data viewer or could we not run out of memory in large solutions?
Thank you for the great demo! One thing ... if you replace your Refresh Window script step with Freeze Window, it will accomplish the same thing and it will flash less.
That makes sense. I did a little testing and found some key things that go with this.
- To have the variable appear you need a refresh window step in the script after the set variable step. If you have just a just a set variable step you never see the single $ merge variable appear on the screen. That was the case in a single step test script.
- A refresh window excuted by another script will clear all of the single $ merge variables set by the first script. This could be great if you want to display information and then have it clear, or it could lead to the information disapearring unexpectedly. I believe that this is why they recommend $$ variables. Since they persist after the script ends, the subsequent refresh will continue to show the information.
- If you have a paused script and execute another script that has variables with the same name, a refresh window in the second script will change the displayed value to the value set in the second script.
- When the second script ends, a refresh window script step in the first script will restore the original value. If the first script ends without a refresh window the value from the second script will display until the window is refreshed.
Thanks for showing me something new.
It is true that you must understand their nature. We simply have never had values disappear unexpectedly and they are quite dependable.
We prefer using conditional formatting on a text object and declare the variables within the Let() so triggers are usually unnecessary. Here is example where normally a calculation would be required. It needs no script.
Bruce and LaRetta,
Very helpful discussion of the powers and limitations of $ variables!
That works for me.
America loves flashy. But this is one of those cases where less flash is better. Good tip!