Components |Functions |June Expermental |Breaks Code Libs created using components

(1) Share

Report

Posted on by PeterCBell_au

107

Creating Canvas Powerapps.

I have a number of components with properties and parameters that interact (eg. date functions specific to my industry) .

I used component output properties to provide functions and those properties used other properties (passing parameters) within the same component. ie. FuncA with parameters a and b may call Func1 and Func2. (eg. property FuncA returns Self.Func1(a,b) * Self.Func2(b) + Self.Func3(a) etc.)

The new restriction means that a data output doesnt have parameters and may only reference the controls on the component (ie. not suitable for general purpose calculations) --> Any of my outputs (that were emulating an output function) that referenced other properties in the same component are now broken.

The output functions may only perform calculations using their own parameters and cannot call other functions in the component.

So... How do I build a base library of functions that can be called by other functions?

Previous documentation suggested 'user defined functions' defined in the app formulas section would be coming, and would be of the form...

udfTest(par1:Number , par2:Number, par3:Number):Number= (par1*par2)/par3

I was hoping that when this was released I could move code out of components and create a number of UDF procedures that were callable from within the app (and by components with app scope) and could call each other.

But trying to enter a udf (using the syntax above) fails. Have UDF's been implemented but using some other syntax??

Related to the above, I dont follow the documentation regarding input functions for components- how do I define a function in the app that has parameters that the input function can make a callback to (ie. a udf as mentioned above)?

from... "learn.microsoft.com/en-au/power-apps/maker/canvas-apps/component-properties""

"The app could define the function expression to return $"{firstname} {lastname}" or it could choose to define an expression for $"{lastname}, {firstname}". The component can just call the function the app maker has provided, and use the returned string."

Categories:

Experimental features

I have the same question (0)

All responses (27)

Answers (0)

JorisdG on at

Like (0)

Report

Hi Peter, great questions!

Let's start backwards from your feedback. User defined functions are currently being worked on. We have our first working alpha version internally. We are hoping to get this out as a first experimental preview in the September timeframe.

Given that, using components as a function library is a bit of workaround for user defined functions and it certainly is useful. The reason functions can now only access arguments and not any variables or controls inside the component is because of data flow. If you're using a control's property and the property changes, your function will not trigger a recalc of the formulas it's used in. This actually does work in the studio, but not in published apps. This caused a lot of confusion and was difficult to explain to makers.

That said, user defined functions will need to fix this data flow issue with published apps as it would otherwise significantly decrease their usefulness. When that is fixed, we will update components so functions can support data flow - at which point we can allow functions to access component scope for variables and controls. I can't make any promises at this point when this would be implemented however.

Was this reply helpful? Yes No
JorisdG on at

Like (0)

Report

To another point you made I didn't pick up on - calling functions from functions is likely something we're blocking that for no good reason (perhaps other to block recursion, but that could be handled separately).

I'll discuss with the team to see if we can unblock that.

Was this reply helpful? Yes No
PeterCBell_au 107 on at

Like (0)

Report

Thanks for the quick reply Joris.
So is it fair to say that the reference to 'callbacks to app defined functions' is premature and will need the ~September release?
While referencing that, from what I can work out components try and deduce the schema being used by tables and records from calculations and default values- which has gone awry for me plenty of times with the components generating their own schema which they then map to the underlying db schema.
Do you think that components should ask you to explicitly define the schema (eg. patients, or defaults(patients) or {name:string,dob:date,children:number}) when you use either of those objects as parameters or return values? Which would also be needed for any UDF eg. a udf is defined in the app formulas section as... ::funcFixRecord(InputRecord as Record(defaults(patients))) as record(defaults(patients))=patch(inputrecord,{....})

Was this reply helpful? Yes No
PeterCBell_au 107 on at

Like (0)

Report
Thank you for recognising that this is a BIG problem for me (app I am working on has gone from zero --> 1800 errors). Unblocking ASAP would be a life saver 🙏

I can see that implementing and maintaining data flows is a complex process, underpins the model and stops the app from hanging waiting for calculations to complete.
On that issue, there are however times when I would like to be positive a data change has taken place before performing a subsequent calculation or action.
If I understand it correctly, it cannot be guaranteed that Set(A,1);Set(B,A+1) ;Set(C,B+1) will result in C being instantly correct? If that is the case could there be a Wait(variable[,timeOutInMS]) function that indicates that a variable must have all of its dataflows completed before further formula processing takes place within the same formula sequence (ie. confined to a single formula sequence with a maximum allowed timeout of say 10ms to prevent app hanging)? eg. Set(A,1);Set(B,A+1);Set(C,B+1);Wait(C);....more calculations or some action invoked

While I have your attention 🙂
Wouldnt it be fantastic if the formula bar could be docked to the side expanded to save the complete PITG which is expanding and collapsing the formula bar repeatedly when the formula is non trivial?
And as a bonus also have the option of docking the control properties as a list (instead of also repeatedly dropping the combo box to select which property you want to view and/or edit).
Greedily, It would also be great if you could expose a windows function that calculated text width by passing text with either a control or (font name, size, and padding) or EVEN better, controls implement an auto-width property?

Was this reply helpful? Yes No
JorisdG on at

Like (0)

Report

In your ordering example C will always be correct. For most intents and purposes just consider the whole state to be single threaded.

Formula bar is being worked on, I can't speak for the team's roadmap but they're aware of the ask of undocking it. Their first priority is the new formula bar (please enable it and provide feedback), they can go from there.

Responsive design is also something a team is actively engaged in. Not sure about the exact things you're asking for, but overall the idea is that you shouldn't have to do these things manually.

Was this reply helpful? Yes No
PeterCBell_au 107 on at

Like (0)

Report

Sorry Jaris, I thought some code was processed asynchronously and have had some problems in the past so took the opportunity to bring it up (eg. see itaintboring.com/powerapps/canvas-apps-sync-processing-vs-async-processing/)

Was this reply helpful? Yes No
PeterCBell_au 107 on at

Like (0)

Report

Also, to pin you down, the documentation regarding input functions and callbacks is referring to a feature that hasnt been implemented yet (since that would likely solve the problem of using components to store general purpose base functions that call each other)?

"Function properties are related to logic, such as performing a calculation based on specific parameters or altering text. A Function property can be set to be Input or Output, which indicates if the component provides a function the app can call (Output), or the app provides a function the component can call (Input). Function properties do not participate in an app's data flow, and cannot use component or app variables."

Was this reply helpful? Yes No
rowza789 5 on at

Like (0)

Report

I also wanted to follow-up here on Peter's comments that I am experiencing the same issue with functions calling functions. Prior to the update I had a number of properly working component defined functions calling other functions and now they all seem to be throwing errors. Is a fix in the works for this as well?

Was this reply helpful? Yes No
JorisdG on at

Like (0)

Report

The functions calling functions wasn't exactly a bug, but we currently have someone actively working on enabling that!

Was this reply helpful? Yes No
PeterCBell_au 107 on at

Like (0)

Report

Thanks Joris. Code only components seemed to be working fine. The real issue was the kludginess of using the interface. More advanced users being able to download/upload plain text would ease my tasks (my organisation keeps me in powerapps studio) which i guess i was hoping udf's were going to bring to the table.

Was this reply helpful? Yes No