New Bug Encountered: Format Rules do not reapply on when returning to formatted view

I have found that it depends on how you have constructed the expression for it.

For example, the bug you mention likes to appear more often for a format rule with
as opposed to
OR(CONTEXT("ViewType")="Table", CONTEXT("ViewType")="Detail", ...)

In general, format rules hate inequality comparisons.


So, I did have CONTEXT() function in my example app.

EDITED: Disregard the below

Have removed them for the affected view and still see the issue.   I do have inequality.  I can test to see if removing those make a difference.

EDITED: I have realized that my changes were not getting saved due the editor “version already exists” bug.

After properly saving the app with the CONTEXT() function usage removed, I DO NOT see the issue - meaning the formats are appearing as expected when navigating BACK to a formatted view.

Reapplying the CONTEXT() function to a format rule on just a single column resurfaces the issue for just that column.

So, it seems that the format rules are removed when navigating away from the view when with CONTEXT() they do not apply but are NOT getting re-applied when navigating BACK to the view when the CONTEXT() does apply.


Hi @Bahbus,

Thank you. It is definitely a better approach to use equality operators.

I quickly tested with a simple format rule applied to table view with equality operator. The format rules seem to be still dropping while navigating back from detail to table view.

In earlier post thread also I had tested with equality operators and the format rules seem to be dropping off.

1 Like

I am not quite sure why you say this. Whether you use “=” or “<>”, it should not make a difference and the “strength” of both should be the same.

I do have inequality in my expressions, like below, and they seem to be working fine:

     ISNOTBLANK([Prior Row]),
     [Prior Row].[Column 2] <> [Column 2]

However, if I add the CONTEXT() function, as @Bahbus points out and done in the example below, this is when I am seeing the problem that has been highlighted to me today. I have run multiple tests and seeing consistent good/bad results.

AND(CONTEXT("View") = "Log Table",
     ISNOTBLANK([Prior Row]),
     [Prior Row].[Column 1] <> [Column 1]

Hmm, it might just be how I have all of mine setup that I don’t see the issues anymore. I remember playing around with them a lot to avoid this exact issue.

But about the inequality on format rules, I think I remember either @praveen or @Aleksi being the one that originally said it, so its mostly just me parroting the information.

In general though, I do feel the formatting engine that runs all of this is due for an upgrade to fix some of these issues.


Hi @WillowMobileSystems,

Please refer to the following post regarding equality operators and inputs by @praveen therein.

As rightly mentioned by @Bahbus , I also remembered this equality related statment as I had specifically noted all inputs in the post as it was a great post in terms of performance improvement.

Edit: However in case of format rules as we tested, they seem to be dropping off irrespctive of using equality operators while navigating back from detail to table view.

1 Like

More efficient:
IN(CONTEXT("ViewType"), {"Table", "Detail", ...})


Also. Yes.

I believe the statement by Praveen you are leveraging is this:

"Equality, IN(), and AND() of these are efficient filter conditions. Inequality and OR() functions lead to inefficient filter functions."

Note that this is in the context of filtering tables. It should not be generalized to all equality and inequality operators/operations.

1 Like

That’s the one! I forgot about the OR() being on the inequality side.

Hi @WillowMobileSystems,

Note that this is in the context of filtering tables. It should not be generalized to all equality and inequality operators/operations.

Sure. Thank you. I have noted and respect your inputs.

Complex format rules have a large performance cost so whenever possible we try to cache the results. The caching embeds the assumption that the results generally remain valid until a sync occurs or a change is made to the table data. Context(“ViewType”) introduced the potential for expression dependencies on application state which was not accounted for in the caching behavior. We’ll need to add some additional checks for this. Should be able to get a fix out soon I think.


The distinction between “=” and “<>” is probably a matter of implementation details. Equality conditions are often handled as index lookups which are generally more efficient than actually running the expression. We don’t typically index “<>” conditions as far as I know.


Thank you for the consideration.

I’m not sure why that might be. The “<>” operation is NOT some derivative of the “=” operation - as some might think. They are two distinct operations with explicit representation…all the way down to the machine assembly language level.

Without going into all the technical jargon, bottom line is that the importance of these two should be the same. In other words, if some process activity is being taken to assure operations based on “=” operator are efficient, the same treatment should be given to the “<>” operator.

Ahh, that would explain basically every question about formatting not working right on here.

@Adam Since you know about this, I have a question for you. How large of an undertaking would it be to revamp formatting completely and move it to the individual Column settings? And could this possibly help make things more efficient on the backend? Where basically, the formatting options for the column exist similar to the Valid If, Show If, etc. settings. It could have its own little section with all the same options available in Format Rules, but only for that column.


We have been discussing potential alternative approaches to formatting.

1 Like

Let’s not forget about Actions! They have the ability to be formatted as well.

A few disadvantages to Format Rules being attached to each column or action:

  • When you need to make a similar change (color for instance) to several format rules, we may need to navigate to many different columns/actions to get those changes made.
  • Some format rules can be easily applied to multiple columns. This helps reduce number of format rules.
  • When there is a formatting problem, it would be much easier to debug it if the format rules are all in the same place.

Maybe there is a way to get the best of both worlds? See them on the column or action if they apply but still be able to view all format rules collectively in a single location?

Thank you for the update! It is much appreciated!

Thank you for the update @Adam.