Put format rule conditions in virtual columns

[Kirk_Masden]

Through trial and error, I’ve come to the conclusion that it’s often better to put format rule conditions in virtual columns. One advantage is that it can help you eliminate the following kind of warnings:

See . . .

Format rule condition vs. Show condition Questions

I’ve been working on a prototype app that is designed to be used by a single user in prototype (free) mode. So, there’s only one user. Since there’s only one user per app, I can have a small table (only a few rows) of “options” from which the user can choose: [Screen Shot 2020-02-07 at 19.19.12] One of the options is “Word” size, that is, an option to change the display size of the vocabulary items in this flashcard app. The size that the user selects is stored in a small “options” table (j…

I’ve also found situations in which placing the condition in a virtual column eliminated inconsistencies in implementation (that is, working sometimes but not always):

New Bug Encountered: Format with CONTEXT("ViewType") not working properly Questions

Recently, I have been avoiding “context” expressions with format rules. Instead, I make virtual columns that I only use in contexts where I want the rule to be applied and then make a format rule just for that virtual column. That seems to work well.

Finally, here’s one more example of a situation where a virtual column solved a format rule issue:

Formatting Bug Questions

Did you try my idea about the additional virtual column. As I say, it shouldn’t really be necessary but it might work. You could make it something like NOT([COL]=“sigbackground.png”) Then, you could test it to make sure that this true/false virtual column was working properly. Then you could make TRUE for this virtual column your condition.

[Grant_Stead]

Agree .
If only they would move this to the view level…

[Marc_Dillon]

Totally agree.

Formatting expressions are calculated upon every view change, so make them as simple as possible. Move all complication to a virtual column.

[WillowMobileSys]

@Kirk_Masden @Marc_Dillon @Grant_Stead

There’s another layer to the use of Virtual Columns that we need to keep an eye on as well. They can extend Sync time - a lot - as we all know!

I have a fairly large app and found that over 8 seconds of a 15 second Sync time was in Virtual Columns. Most of those VC’s are static data pulled in for display purposes only and will rarely change.

I have decided for these VC’s it might be better to store them as normal columns. I can then build a Workflow to update those specific column values should the underlying reference data change. This pushes that processing time into the backend AND only needs to be done on each change NOT on every Sync as is done with VC’s.

For what its worth!!

By the way, the app above is not deployed. Should we expect a difference in the Sync times once the app is deployed?

[Marc_Dillon]

WillowMobileSystems:

I have decided for these VC’s it might be better to store them as normal columns. I can then build a Workflow to update those specific column values should the underlying reference data change.

I have also setup a few apps with this approach, and in general try to use real columns when possible instead of abundant VCs.

I don’t think deployed apps get any kind of special sync speed treatment.

[1minManager]

One downside of using virtual columns that I’ve just had is that is they don’t update in offline mode. I had some action formating rules that changed colour and icon, which relied on a 2 x VC’s. The client decided it had to work offline so I’ve had to merge the code in format rule. Odd thing it is basically identical. So begs the question why VCs can’t work offline. Surely Appsheet could let the sync still run just to calculate all the VCs based on the information the offline App has?

[Fabian_Weller]

Format Rules with deref expression may work better than using a VC.

Format Rules Delay when referring to the Parent Table Questions

AppSheet finally fixed this problem. Thank you @Gil So now the Map Pin get’s formatted immediately. Because I use a deref expression in the format rule. In the Table view I use a VC with the same deref expresion. But this needs a sync to calc. And also the Format rule based on that VC needs a sync to be applied. [FormatRule2] To conclude I think this statement is true: When we use a deref expression in a format rule, it will be applied immediately. No need for sync. Like: [Pare…