For Power Apps29 juni 2026

Scripts on a screen

Everything a drawn screen does is written in BS, in a code editor inside Parsware Studio. The editor knows your Dataverse environment, so it offers your tables, then their columns, as you type, and it underlines a mistake before you save. Here is how to use it.

Dit artikel is alleen in het Engels beschikbaar.

The code page in Parsware Studio: a loadRecords call with its table name half typed as par_ca, and a list offering the Case table, par_case, next to the title "Scripts on a screen"

Every screen in this series does its work in a few lines of script: a list that loads when the screen opens, a chart's numbers, a button that writes a column. Those lines are BS, Parsware's scripting language, and you write them in a code editor inside Parsware Studio.

The editor knows your environment. When a line needs a table, it lists your tables. When it needs a column, it lists that table's columns. And it underlines a mistake while you type, rather than leaving you to find it on a form.

We'll use the Case overview design from Screens that read Dataverse rows.

1. Open the code page

In the designer, select the object the code belongs to and press </> on the toolbar. For a screen, that's its frame: select Overview, press </>, and choose Screen opens.

The code page for the Overview frame: on the left, the screen's state fields high, normal, low, probe and latest, then its bindings Text, Shown, Chosen and Timer interval, then its events from Pressed to Timer ticks, with Screen opens marked Written; on the right, the four loadRecords lines that load the counts and the newest cases

The left side lists everything you can write code for on the selected object:

Screen state: the fields the screen keeps its values in.
Bindings: values the object shows, such as its Text, or whether it's Shown.
When this happens: events, such as Pressed for a button or Screen opens for a screen.

A dot marks what's written. It turns red when the code has a mistake, so you can see which part of an object is broken without opening each one.

2. Bindings and handlers are different

A binding is one expression that works out a value: state.high > 0, or row.par_name. It runs again whenever what it reads changes, so it can only read. It can't change anything.

A handler, under When this happens, is a list of statements that runs once each time the event happens. That's where you load rows, change state, write a column or open something.

The line at the bottom of the page reminds you which kind you're writing.

3. Ask for help with Ctrl+Space

Put the cursor on an empty line and press Ctrl+Space. The editor lists everything you can call, with its arguments:

The code page with a list of functions under the cursor: callApi, changeName, changePassword, closeDropdown, closeEndDrawer, closeModal, and more, with callApi's arguments method, path, inputs and into shown beside it

Type the first letters to narrow the list, and press Tab or Enter to take one. Once you open the bracket, a card above the line shows what each argument is for, and which one you're on.

4. Pick a table instead of typing it

loadRecords needs a table's logical name, and a misspelt one looks exactly like a table with no rows: the screen is just empty. So don't type it. Open the quotes and press Ctrl+Space:

loadRecords with its first argument open, and a list of the environment's tables by display name: Account, Action Approval Model, Activity, Activity File Attachment, Address, Agent

These are your environment's tables, shown by the name you know them by. Type part of either name to narrow the list. Here par_ca finds Case:

loadRecords with par_ca typed inside the quotes, and the list narrowed to Case, par_case

Take it, and the editor writes the logical name, par_case, which is what the script needs.

5. Pick a column too

The same works one level in. In a where, the editor knows which table the line is about, so it lists that table's columns, with each one's type:

A loadRecords line for par_case with where open and prio typed, and the list narrowed to Priority, par_priority, OptionSet

It does the same for orderBy, and for the values you pass to createRecord and updateRecord. The list comes from your environment, so a column you added this morning is in it.

6. Your screen's own names

After state., the editor lists the screen's state fields:

notify(state. with a list of the screen's state fields: high, latest, low, normal and probe, and a card above saying notify tells the person using the screen that something worked

When you write code in a component's own drawing, props. does the same for the component's properties.

7. Mistakes are underlined as you type

Write something the editor can't make sense of and it's underlined in red, the dot beside the slot turns red, and the panel under the editor says what's wrong and where:

The code page with a sixth line, notfy("Loaded"), underlined in red; Screen opens is marked Has an error, and the problems panel reads 6:1 Function notfy not found

Here notify was spelt notfy. Click the problem to jump to it, or press Copy to copy the list. Half-typed code always shows a problem for a moment, until you finish the line.

The editor also knows which kind of code you're writing. In a binding, a function that changes something isn't there at all:

The code page for the Shown binding with setState("high", 0) underlined; Shown is marked Has an error, the panel reads 1:1 Function setState not found, and the line at the bottom says One expression that only reads; it runs again whenever what it reads changes, so it must not change anything itself, put that in a handler

Move it into a handler, such as Pressed on a button.

Good to know

Nothing runs until you publish. The code page writes into your draft. Save keeps it, and Publish is what reaches your users (see Publish: drafts versus what users see).
Close without saving to throw a change away. Trying something out in the editor costs nothing.
It reads as the person using the screen. A script that loads rows asks Dataverse as the signed-in user, so it sees what their security roles let them see.
A table named by a variable isn't looked up. loadRecords(state.table, …) names a table that only exists when the screen runs, so the editor can't offer that table's columns.

When a control can't load: the messages the Parsware control shows on a form when something is wrong, and what each one means. The whole series is in the reading list.