Hi Joris
Please excuse this rather long post. I have used canvas for a few years now. I know that as a product develops inconsistencies develop, with the difficulties associated with maintaining backward compatibility.
For me, as apps have become bigger with more screens and components life has become a bit difficult in powerapps. With the ongoing development and pending release of UDF's, might I make some observations and suggestions regarding the coding environment?
#The use of Self and Parent can be confusing, especially in components (eg. Self may refer to a controls properties or to the component controls, data, etc and parent may refer to a controls hosting component or a control container). I can use the explicit component name, but..
Wouldnt it be better to have a reserved word 'component' where the use of component.x refers to a control or property x of the current component and a reserved word 'host' for use when referencing an object hosted by the current screen (eg. host.width instead of parent.width or myscreenname.width)?
#Set used for both global variables and local variables within components. Within components the use of Set(x,..) maintains a property x which is limited to internal use within the component. Especially if app scope is enabled, it can be confusing what the scope of x is...
Perhaps a SetLocal(x,...) function which allows use of x within the component only and references to x requiring Local.x
#UpdateContext and knowing what is or isnt local. Allowing local variables limited to the scope of a screen sees the UpdateContext() function maintaining an internal record of variables local to the screen it is used in (ISR). When variables defined in that record are used it isnt obvious that they are local...
In line with above, allow SetLocal(x,..) to patch the ISR and use Local.x to reference property x within the ISR?
#Components and controls within a screen default to app scope. Allowing processes to reference a controls or components in other screens, it seems to me, should only occur with very specific intent. Personally, I only do that for global components, as a work around for code libraries. It also creates a burden for the formula editor intellisense.
Perhaps controls and components within screens should have an appscope property defaulting to off for newly added objects and on for backward compatibility?
#Formulas. Formulas are, to my mind, a means of maintaining an on demand variable, which would be equivalent to SetOnDemand(x,...), which recalculates x when used and/or a dependent changes. Having those in app.Formulas means they are all global variables, tends to break the app if there is a single error in that store, and leads to a large app.Formulas section.
I think each screen having its own OnDemand store that manages local OnDemand variables would be an improvement.
#Code Blocks. At the moment, reusable code is often stored in hidden icons/buttons and Select() is used to execute code. In effect, no parameter code blocks.
Apart from being messy and difficult to maintain, it creates problems if the interpreter, in the name of responsiveness, ignores hidden controls until they are visible.
Would it be better for both the app and each screen to have their own CodeBlock stores, containing one or more code blocks- code blocks being able to access local variables, global variables, controls within the current screen (for a screen codeblock), etc. ?
#UDF. A UDF store, to my mind, would store a set of functions that only reference passed parameters.
Again, there could be app.UDF and screen.UDF stores?
Since they are different in concept to on demand formulas, would they be better having their own stores?
#UDF parameter types. I hope that UDF's will accept controls as parameters. eg. UDF: CenterControlX(c as label) as integer;return (c.parent.width-c.width)/2
#UDF code. I hope UDF's wont simply be power FX with parameters but will allow intermediate calculations with a return type. eg. SetLocal(x,..);SetLocal(y,...);Return x+y
#Discovering table and record variables properties. When a variable is selected in the formula bar it would be useful, along with its current value and data type, to have a link to see its schema (as understood by Power FX at that instant).
#Screen instantiation. There is usually code that ends up being in the screen.OnVisible event that should only be run when a screen is first created. At the moment I usually have a context variable that tracks first visibility, but something like Self.VisibilityCount or Self.Initialised (set to true when onvisible completes the first time) maintained by canvas might be better?
#Navigating code- Jump to. Other editors allow you to jump to code. eg. If code contains Select(myControl) then say, highlight 'Select(myControl)' and hit F2 for the editor to open the formula editor at OnSelect() for myControl, and Shift+F2 to jump back to your original code.
I am sure I could go on 🙂
Thank you for your forbearance and Merry Xmas.
Regards
Peter
Share
Report
105
All responses (
Answers (
