Calcapp Creator has always allowed you to edit multiple items (including fields and buttons) at the same time. Simply check all the relevant items (which as of today is a lot easier) and make changes in the inspector. You’ll find that the changes have been applied to all the relevant checked items.
For instance, let’s say that you have created 100 currency fields, but forgot to change the currency from the default. Simply by checking those 100 items (which, again, is now easy) and selecting the desired currency once, the changes are applied to all relevant checked items.
Traditionally, that has not applied to formulas, though. Previously, if you checked multiple items, the fx symbols next to calculated properties in the inspector would go away, and the property selector and the formula field would be grayed out.
Today, that changes. Now, when you check multiple items and select a property whose formulas are either missing or are identical across all checked items, you can simply edit the formula once, and have the changes apply to all relevant checked items.
Here’s an example app, where we want the Visible properties of all checked fields to use the same formula:
As you can see, we are allowed to edit the shared formula of all five checked fields.
So what happens if the relevant formulas aren’t all identical? The formula field will then display a message to that effect:
To resolve the issue, just start typing in the formula field, and you’re presented with this box:
Select a single formula, and that one formula will be set for all items.
Referencing the current item from a formula
In the example above, all formulas reference the same switch field. What if you instead want to reference the item the formula belongs to?
Whether a field is valid typically depends on the value of the field. Let’s say that the relief pressure valves in the example should not be assigned values that are less than 110 psi or greater than 200 psi.
Normally, making this work for all fields is fairly easy. We simply check them all, and enter 110 for the minimum value and 200 for the maximum value under Validity in the inspector.
Let’s add a complicating wrinkle, though. Let’s say that having fields validated can be annoying at times, and it is imperative that users can disable validation. To achieve that, we add the switch field ValidateValues.
Suddenly, we can no longer rely on the minimum and maximum values in the inspector, now we need to determine validity using a formula.
(We could use either the Valid property, or use both the MinimumValue and MaximumValue properties. Here, we’ll somewhat arbitrarily do the former.)
Here’s the Valid formula for Valve1:
In other words, the field is considered valid if the ValidateValues switch field is toggled to its “off” position, or if the value of Valve1 is greater or equal to 110 and less than or equal to 200.
Here’s the almost-identical Valid formula for Valve2:
It would appear that we can’t use a single formula for all fields, as
all the formulas need to reference the relevant field and its
value: The
Valid formula for Valve1 must reference
Valve1, the
the Valid formula for Valve2 must reference
Valve2,
etc.
That’s where the new Item value comes into
play. All formulas associated with items have access to this new
special value, and it always references the current item (including
fields and buttons).
That means that we can use a single formula for all the fields after all:
As such, this feature enables you to conveniently edit the shared formula of all five valve fields of the example at the same time.
Note that when you access Item from a formula,
what you are accessing is the entire item, and not just, say, a field
value.
That means that this formula, associated with the BackgroundColor property of a field, will work:
In other words, the background color of a field will turn red if the item is not valid.
Related performance improvements
We expect that this feature will lead to many more apps with identical formulas, as they are now so easy to create and maintain. For that reason, we have done a lot of work in Calcapp Connect (which runs your apps) to ensure that apps with a lot of identical properties, and identical formulas, run faster and consume less memory.
This section is somewhat technical. Feel free to skip ahead to the next blog post if you’re not interested in the details.
Before, if you had 1,000 fields which all used the same Visible formula, Calcapp would needlessly create 1,000 identical so-called property instances when your app was run.
A property instance is necessary when a property is associated with a formula. They consume memory, and make your apps run somewhat slower, so we try not to create them unnecessarily. For instance, if your field is always visible, we’ll just make a note of the fact that it’s visible, without creating a property instance, and the same goes for all properties with unchanging values.
We did create them unnecessarily before, if lots of items shared the exact same formula. It was unnecessary, because a single property instance would have sufficed.
That’s exactly what we do now. We look at all your formulas when your app is run, and we let items share property instances if they aren’t different from one another. The end result is that such apps start and run faster.
We’ve done that work for another reason as well: the new Items property, and related properties, make it easy to access potentially thousands of items in one fell swoop.
You can, for instance, make the background color of the app red if any field in the entire app is invalid, by associating this formula with the BackgroundColor property of the first screen:
Colors are actually fairly complicated in Calcapp. If a screen doesn’t have a background color set, it uses the background color from the preceding screen, and so on. Ultimately, if no preceding screen has a background color set, it uses the one from your theme.
For various reasons, the formula above used to cause an explosion in the number of property instances that were created, especially for very large apps. The end result was that our powerful desktop computers in the office could barely run a simple, but large, test app that used the technique described above.
Now that property instances are shared if possible, that large test app runs very quickly. That means that you shouldn’t run into situations where your reasonably-sized apps run slowly, even if you use all the new features of this release.