Examples of Control validations in PowerApps



Many times we have situations where we need to validate various controls on any form. Doing this on PowerApps forms is tricky (being a techie, your default psyche would be to write one line of code to achieve this -- however as you know, that is not the case with the PowerApps: courtesy its low code, no code philosophy 💔💔💔).

To check if a control is empty:

The following form contains an EmplId field, which is a mandatory field. We can add a label file like this:



Go to the label file's Visible event:


And write on the following formula:

To check if an entered Email Id is correct:



And then in the visible event of the label control, you write:



As a result, when you run the form, as a preview:


Giving something gibberish will give you an error like this. However, giving a proper email Id, this label disappears:


Date control validations:
Similarly, we can embed a datepicker control and ensure that the user doesn't select a future date, simply by writing:







Conditional visibility of controls:

When an employee's age is above 50, then suppose the organization makes him to invest in NPS. The following arrangement can help you with that:

The slider control allows the user to choose any value between 25 to 60. The below label and controls can be made to be given a visible event that says:

Working with signatures (pen input controls):
Pen input controls are an amazing feature of PowerApps, that can help the user to validate and store their signatures. Go ahead with selecting a 'Pen input' control from the 'Insert' drop-down list:

 You can resize the resulting control to occupy the maximum width of the screen form:

Pen controls can be used just not to capture the signature, but also
a. You can reset/remove whatever you have drawn
b. You can change the color of the pen while signing.
c. You can erase the drawing if needed.

Now, go to the signature control, select Advanced >> OnSelect event:


Here I am storing the value of the image in a local variable called: ImageContent >>


Validating the user doesn't submit without signing:
On your submit button >> DisplayMode event, write the following:

It checks the value of the local variable with the input image value.
Consequently, as long as you are not writing any signature, the submit button won't be enabled at all:


Signing on, will enable my submit button:


So much for today. Will come back with more insights and examples of PowerApps with D365FO, soon. 
Stay tuned.👋👋👋

Comments

Post a Comment

Popular posts from this blog

Make your menu items visible on main menu, conditionally,, using this cool feature of D365FO

Image
  Wassup guys? I am sure you must have encountered this situation where you needed to display your menuItems, on main menu, based on some condition, haven't you? This was only possible by using config keys and flights. Things get a bit tricky,  when suppose you have a requirement like this: you need to make it dynamic, by introducing a toggle switch on a field on a paremeter form.  Suppose on Accounts Receivables Parameters >> You have a field called ' Show US customer '. You have a requirement that says when you turn on this toggle, then only the menuItem ' Input SSN details ', under AR module. This is now highly acheivable by leveraging subscription to 'SysMenuNavigationObjectFactory' class, simply by saying a. Create a new class USMenuItemsVisibilityManager b. Copy the following method, with proper documentation (don't change signature/anything else) [SubscribesTo(classstr(SysMenuNavigationObjectFactory), staticdelegatestr(SysMenuNavigationObjec...
Read more

X++ : mistakes which developers commit the most

Image
   The most important thing is to remember where and when to write the code. a. Developers have an inherent habit of writing erratic select statements: select * from custTable where custTable.AccountNum == <SomeValue> Where in essence we need to make use of optimized choice of fields in the select statement. b. Making use of 'continue' keywords: While select custTrans where <someConditions> { if (cusTTrans.CustGroup != mappingTable.CustGroup) { continue; } } 'Continue' statements are precisely a very unhygienic way of designing your code. The above statement could have been easily ornamented by using exists/not exists joins. Using Continue statements would eventually result in a high performance impact. Also select statements should be made punctuated with a 'firstonly' clause -- just not from best practise standpoint, but also from performance considerations. c. Writing nested loops: This is a common mistake that perha...
Read more

Are you still using macros? Be sure you read this.

Image
  You still use a lot of macros in your code, don't you? Of course you should: Macros, as per Microsoft,  are p recompiler directives are processed before the code is compiled. The directives declare and handle macros and their values. The directives are removed by the precompiler so that the X++ compiler never encounters them. The X++ compiler only sees the sequence of characters written into the X++ code by the directives. However macros, are not quite recomended by Microsoft. They are slow, they can be subsequently deorectaed at any later time.  The Macros are  actually  a type of classes, only that they are not instantiated and not need be defined as classes. Hence runtime garbage collection could be a huge issue, consquently (a class when gets out of scope, gets garbage-collected owing to the destructor classes of DOT net instrumentation classes). Summing up, macrros are a bit old way of writing code. Use static classes instead. public static class MyIdenti...
Read more