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

I am including a video link below.

When in a Table view that has Format Rules applied, tapping a row to go to Detail view or tapping on the Add button the Format Rules are removed from the Table View just before navigating the new view. If you watch the video closely you will see these formats are removed just before the navigation.

If a cancel action - e.g. tapping the back arrow in Detail view or tapping Cancel button in Form view - is applied to go back to the Table View, the Format Rules are NOT reapplied. A Sync must be performed to reapply the formats.

3 22 881
22 REPLIES 22

Hi @WillowMobileSystems ,

Yes, your observations are on similar lines as per below post. @Kirk_Masden had also mentioned it in a still earlier post.

It has been brought to my attention, that by simply navigating away from a view that has formatting applied and then navigating back to that view removes the formatting. A Sync is required to get them back. This is a BIG problem that is potentially affect business/client end users and needs addressed right away.

Reaching out to appsheet support to garner more attention.

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
CONTEXT("ViewType")<>"Form"
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.

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:

AND( 
     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]
)

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

Also. Yes.

Bahbus
Participant V

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.

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.

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.

Thank you for the consideration.

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.

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?

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.

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.

We have been discussing potential alternative approaches to formatting.

Thank you for the update! It is much appreciated!

Thank you for the update @Adam.

Top Labels in this Space