This blog series
PowerApps is a fantastic tool that can allow you to quickly create incredible, powerful, and visually engaging applications to replace your manual business processes. It’s an extremely fun platform to work with that empowers everyone to be able to create professional applications, regardless of background, with an ever-growing collection of incredible features.
The one down side? With the breakneck pace that Microsoft are introducing new functionality, and the myriad of features available, it can be quite daunting trying to find how to start learning to use PowerApps. But never fear! This blog series is designed to take you through my experiences learning PowerApps and provide you with the right steps to take to start your very own PowerApps Journey!
Learning PowerApps with @Clarissa2 – #2 Using Controls in PowerApps
In the last instalment we covered the basics of how to get started with an Office 365 environment, familiarised ourselves with the PowerApps Editor and started to see what elements we could add to our application and the out-of-the-box functionality that comes with them.
But what if we want to do something a bit more special with these elements?
If you read through the intro to the previous article you might remember I mentioned that there were some basic concepts from my programming background that have given me a head-start when learning PowerApps. In this article I’ll aim to outline the basic information that I personally think everyone needs to know to start their PowerApps Journey, starting with Objects, Types and Expected Values. Don’t panic if any, or all, of these terms are new to you and if you have any questions that this article doesn’t cover, always feel free to contact me on Twitter @ClarissaGillin2!
What is an ‘Object’?
The concept of Objects is something that can sound intimidating, but in real life we use it every day. An Object can be defined as simply a collection of Properties and Behaviours.
This is always easier to imagine when we have a real-world example, so let’s consider a pen. It has Properties, like the colour of the ink and the type of pen i.e. is it a fountain pen or a ball point? It also has Behaviours: for example, when we use the pen, it uses up the ink. When we run out of ink, the pen will not work anymore.
We can use this information to provide us with a basic blueprint for a pen:
Properties: Ink Colour,
Behaviours: On Use: uses ink,
When Empty: doesn’t work
What does this mean for PowerApps?
If you were to go into your brand new Canvas App and add a Button control, what you’d actually be doing is adding what is called an Instance of the Button Object into your application. Whereas an Object can be thought of as a blueprint for creating an item, an Instance is the result of that blueprint. For example, we have one Object, the humble pen, which has many Instances all throughout the world. The pen on your desk is one specific Instance of the pen Object; we know it is a pen by the properties it has and the way it behaves, and you know it is yours because it lives on your desk.
It’s important to note that while all Instances of the same Object have the same Properties and Behaviours, each Instance can have different values assigned to its Properties and Behaviours. A red pen and a blue pen both have a Property Ink Colour because they are both pens, but the value of that property is different for each Instance (red and blue respectively). In PowerApps, when you type in the Formula Bar you are assigning a value to an Instance’s Property or Behaviour.
This means you can have multiple Instances of a control, like the Button, in your application, and all will have the same possible Properties and Behaviours – since they are defined by the Button Object – but can be assigned different values: for example, Button1 can be orange and toggle which icon is shown, whereas Button2 can be grey and Navigate us to another screen.
While in more conventional programming, often one of the trickiest parts is correctly identifying the Properties and Behaviours to create the perfect Object blueprint, the great thing about PowerApps is that Microsoft have already done the hard work for you. If you select your Button and look in the top left-hand corner of the editor, you’ll see a drop-down list of Properties and Behaviours that belong to the Button. This means the button you have created with a single click has already been pre-populated with a series of Properties and Behaviours, because the Object has already been defined by Microsoft.
However, there’s still some work to be done! If we select “Color” from this drop-down list, you’ll see there’s nothing actually telling you, “Hey, this is a property”. Similarly, if we select “OnSelect” from this list, there’s nothing that pops up and says, “This is a behaviour”. In order to know how to use each Object, i.e. how to assign the correct values to an Object’s Properties and Behaviours, it comes in handy to understand the difference between the two.
Expected Values of Properties
For every Object, each Property or Behaviour of that Object has an Expected Value, which allows the computer to start to make sense of the information we are telling it. Importantly, Properties and Behaviours have different Expected Values. Let’s look at the Expected Values of Properties first.
When you define a Property, the system will expect you to enter a single value of an acceptable Type.
For example, for the Property ‘Ink Colour’, we expect a value that is a colour, i.e. red or green. If we try and tell the computer that Ink Colour = Potato, it won’t understand what to do with that information, because “Potato” is not something it understands as a colour. It also won’t understand Ink Colour = Red, Green, Yellow, Blue because it’s only expecting one result. It’s the age-old: if you have a square sized hole and try and fit a cylindrical block of wood through it, it’s not going to fit. Similarly, if you have a square sized hole and two cubes the same size as the hole, you won’t be able to get both through at the same time.
For ‘Ink Colour’ the Type of value we are expecting is quite self-explanatory, but what happens when we get to a slightly more nuanced example? What Type do we expect for, for example, the ‘Pen Type’ we have defined as a property of the pen?
To answer these questions, we’ll have to dive a little deeper into the concept of Types.
A Type can be thought of as a flag that is attached to a value that explains the context of that value. The value “Red” with no context can be interpreted the word “Red” itself or as the colour “Red” – if we don’t tell the computer what we mean by “Red” then it becomes a horrendous guessing game we are all likely to lose. Instead we attach a flag to our value “Red” that says “Colour”, so the message we give the computer is, “Here is a value. The value is Red and it is of type Colour.”
We can also flag empty spaces for values so it knows what Type to expect and, by extension, what values to accept. This means that our Ink Colour Property knows that it is waiting for a value to be entered that is of Type Colour, and it will turn any other values away at the door.
Available Types in PowerApps
According to the official documentation (which I would highly recommend you check out), there are 17 Types in PowerApps. That can seem a bit overwhelming until you realise that you are unlikely to be using all 17 every day. In fact, you are unlikely to be using all 17 in a single solution! Instead let’s have a look at a shortlist of the most commonly used ones to get you started:
|Text||A ‘string’ of characters denoted by quotation marks around the value.||“Text to add”
“Text, including punctuation, to add”
|Number||A numerical character. Can include a decimal place.||1
|Color||A type containing colour information in a variety of forms.||Red
|Boolean||A true or false value. Can only take these two values.||true
|Record||An item containing multiple data values.|
While the first few in the list might seem quite innocuous, Boolean and Record can, at first, be more difficult to get your head around, but in actuality they are still quite simple building blocks.
A Boolean value is just a value that can only be true or false. This is useful for situations where we want to query if something is the case – the answer “yes” or “no” can be represented as true or false – or in any On/Off situations. When we come to making comparisons between values and making logical expressions, you will come to see just how invaluable the humble Boolean can be.
A Record value is more easily imagined by considering a table, like the one above. Every entry in the table is a Record. So, in the case of the table above, every Record has three Fields – Data Type, Description and Examples – which all have values assigned to them. This is our first example of a complex Type: since the individual fields in a Record have Types of their own (in our case the field ‘Data Type’ contains a value of type Text), we have a Type defined by the Types contained within it. This can be a bit mind-blowing, but for now, it’s easiest (and probably best!) to just consider a Record to be a line entry in a table.
So returning our pen analogy, we can now start thinking about what Type the ‘Pen Type’ Property would be expecting.
There are actually a few different options. First, it could just rely on a Text value, which would allow the Pen Type to be equal to “Fountain Pen” or “Ballpoint Pen” or any other string of text the user types in. Unfortunately, the lack of limitation on this type means that the Pen Type would also be able to equal to the misspelled “Foutnain Pen” or, if you have a very imaginative user, a “Banana Pen”, “Unicorn Pen, or “Chocolate Cake”. All of these values are of type Text, thus if there is no further validation going on using this Type could result in a load of un-useful data.
While it isn’t intuitive, it could theoretically use a Number Type to do the trick too. For this we would have to create a key that would let us know that ‘1’ means ‘Fountain Pen’, and ‘2’ means ‘Ballpoint Pen’. If you’re somewhat familiar with programming you might recognise this as Enumeration (or enum for short). While in other languages enums can be very helpful, they aren’t actually a supported Type in PowerApps. This means that if you were to try and create an enum in PowerApps you’d have to hold your ‘key’ in your head, or on a piece of paper or a Notepad file somewhere, so it can very easily get confusing – in my opinion it’s always best to value transparency and readability in your code, since it’s highly unlikely that you’ll be able to come back to your app three months later and remember what you meant by ‘Pen Type’ = 3!
Similarly if we have only two types of pen, “Fountain Pen” and “Ballpoint Pen” for example, it could be expecting a Boolean to describe the ‘Pen Type’ since we have an Either/Or situation: i.e. rather than asking the question “What ‘Pen Type’ is this Pen?” it’s asking “Is this pen a Fountain Pen?”, which has a yes or no answer. As you can probably already tell, the limitation of this choice is that it only works if we have an Either/Or, so a maximum of two options. This solution would provide no insight into whether the pen is a Gel Pen, or a Felt Tip Pen, for example, and so is unnecessarily limiting.
So could it be expecting a Record Type? Again, remember that a Record is essentially just a row in a table. Could we represent ‘Pen Type’ in a table format? Certainly!
|Felt Tip Pen|
Fineline Pen (etc.)
Even though it’s just a single column table, this is a good encapsulation of the different ‘Pen Types’ we can choose. Each Instance of pen around the world has a ‘Pen Type’ equal to one of the rows in the above table; this is exactly how a Record Type works and definitely the best way to represent ‘Pen Type’!
However, while we can use the above logic to determine that Record is most likely to be the Expected Type for Pen Type, how can we know for sure?
How to tell what Type a formula is expecting
For pre-generated objects, we can determine what Type of value a Property is expecting by looking at the default value. For example, when we first add a new Button, the default value of the Text Property is “Button”. The fact that this value is in quotation marks signifies that it is of Type Text.
However, this method requires the user to have the experience to be able to recognise data types by examples. Thankfully help is at hand! An easier, and better, method is to Enable Formula Bar Result View in your app settings. This setting is an Experimental Feature, which means we should always remember to turn it off before publishing commercial applications, but for developing and especially for learning I would highly recommend always having this turned on. It has single-handedly saved me so much time debugging my formulae.
You’ll notice that now the Formula Bar Result View is enabled, when we click on a value we see, underneath the Formula Bar, the Data Type displayed in bold. This means that we can determine the expected type by simply clicking at the end of the value we wish to determine the type of.
Another useful thing to bear in mind is that if you go wrong, PowerApps will tell you and try to help you out. When a mistake is made in a formula, the red squiggly line we’re all familiar with from Microsoft Word appears underneath the problematic code. Hovering over the code underlined in this manner can display an error message; you may come across a variant of the “Expected a value of Type X, but received a value of Type Y” error message when making mistakes in your application. Hopefully now you will be able to understand what this error means and so take your first steps to fixing it and getting your app back into tip-top shape.
Finally, remember the editor is always there to help. Values of different types appear in different colours in your formula bar (for instance, Text values will be in a dark red text, Number values will be in orange text), so it’s easy to tell what type a value is at a glance.
Making reference to an Instance’s Properties
One final incredibly useful thing about Properties: we can make reference to the Properties of an Instance of any Object. We do this in language every day, normally by using an apostrophe. In programming we use the following syntax instead:
For instance, if I were to say “Ben’s pen’s ink colour is blue”, this would ‘translate’ in code to <Ben’s Pen>.<Ink Colour> = blue. If I were to say that “My pen has the same ink colour as Ben’s pen” I could say: <My Pen>.<Ink Colour> = <Ben’s Pen>.<Ink Colour>.
This starts to open up a world of possibilities since we can link properties of different objects together – by determining the Colour of Ben’s pen, you would know the colour of my pen, and, more significantly, by altering the Colour of Ben’s pen, you would (programmatically) alter the colour of mine.
What’s next for you in PowerApps?
Now you can start assigning Values to the Properties of the different elements you add to your Canvas Apps, and start to play around with making reference to Properties of other components! In the next article we’ll be looking at Behaviours and how you can start to really ramp up the Power in your PowerApps. Stay tuned!
I hope you’ve enjoyed this next step on the way to becoming an App Maker! If you have any questions, want to strike up a conversation, or want regular updates on all things PowerApps, Microsoft Flow and Power BI, make sure to follow me (@ClarissaGillin2), Ben Haynes (@disappointmentb) and @SilversandsLtd on Twitter.
I recently hosted my first webinar on everything you need to know to get started for PowerApps so please do check out the video from that! If you can’t wait for next my next blog of the series, contact me using the form below, join one of our regular workshops and webinars or checkout one of our other blogs.