This is a quick follow up to Tuesday’s article, and to avoid unnecessary repetition I will assume the reader is familiar with that material.
Demo Files
- button bar segment fun, v3 (from part 1)
- button bar segment fun, v4
There were some things in v3 I wasn’t completely happy about, and I realized this morning that they would be easy to fix, and that the act of fixing them would help demonstrate the power of using this approach in the first place.
Demo #3 Revisited
The first thing I wasn’t happy about in demo 3 was that I had configured $$subheading.array as
[ "Pct", "Est", "Act" ]
…when I would have preferred it like this…
[ "Est", "Act", "Pct" ]
…to reflect the order of the column headings on screen.
Well one of the neat things about the approach we’ve been looking at this week is how easy it is to prototype changes (and indulge one’s OCD). If we open up the Data Viewer and go to the Current tab…
…we can double click on $$subhead.array, change it like so, and click OK.
And since we’ve changed the order of items in the array, let’s make a corresponding adjustment to $$subhead.definition.
Click OK to lock in this change, and now let’s return to the main demo screen, and do something to refresh the on-screen display, e.g., pop into find mode and back into browse mode.
And the net result should be no visible change, since we a) re-arranged items in the array, but then b) adjusted the definition to compensate.
Just for fun, let’s go back to the data viewer, and change $$subhead.array to
[ "A", "B", "C" ]
And after another refresh, here’s what we now see in the main demo.
Now return to the Data Viewer and change $$subhead.array back to
[ "Est", "Act", "Pct" ]
and click OK, because it’s time to address a client request. Remember those directional sort indicators we implemented the other day?
Well the client wants those little triangles to be red rather than black. And it will take us all of about 60 seconds to prototype, if we adjust $$subhead.definition like so:
Looks pretty good to me. I think the client will be happy.
Demo #4
In demo 3 we prototyped some changes by editing a couple variables in the Data Viewer, but we didn’t actually modify any schema. In demo 4 those changes have been implemented, which is to say two steps where variables are defined in the startup script have been updated. Additionally, the inactive state of the clickable column labels has been changed from black to blue.
This leads to another client request… the blue label color is great for browse and find modes, but when the client goes into preview mode or decides to print…
…she wants those labels to be black rather than blue.
Under these circumstances, one might be inclined to implement the fix via Conditional Formatting. But in keeping with the goal I mentioned last time of “concentrating logic into the segment calculation and reducing schema dependencies elsewhere”, we can take care of this by making another adjustment to $$subhead.definition:
Yep, that works.
