Bug or feature? On Change not firing for Input in Gallery when scrolled away

(0) Share

Report

Posted on by CU24021301-0

I've come across a possible corner case where the On Change property for Input controls does not function correctly when embedded in a Gallery in a specific scenario.

Overview of Gallery setup:

- Gallery with each row containing multiple Text Input controls.

- OnChange property of each input control set to update a value in a Collection (separate to the Items source for that Gallery) via a Patch function.

- When tabbing from one input to the next within the same row of the gallery, the OnChange function fires correctly.

Steps to replicate the issue:

- Select an Input control in the Gallery,

- Enter a value,

- With that input still selected (caret flashing), scroll down until that input is hidden

- Select an input on another row now visible.

- The OnChange property for the originally selected Input control does not fire, despite the entered value remaining visible when scrolling back up to that row.

Does anyone know of a workaround for this specific issue? If a user is quickly scrolling through and updating the gallery, it is not obvious if the input has not updated the backing collection.

Categories:

Building Power Apps

I have the same question (0)

All responses (2)

Answers (0)

Sort by

Suggested answer

Inogic 1,291 Moderator on at

Like
a
(1)

Report
Copy link

Link copied!
Hi,

I was able to replicate the same behavior in a Canvas App gallery scenario.
When a TextInput control inside a Gallery is updated and the user scrolls away while the input is still focused ,the OnChange event may not fire in certain cases.

This behavior is related to gallery virtualization in Power Apps.

Galleries only keep visible rows loaded for performance reasons.

When scrolling through a large dataset, rows that move out of view can be unloaded.

If the TextInput loses visibility before a proper focus change occurs, the OnChange event may not trigger As a result the Patch() logic inside OnChange does not execute.

Important Observation
This issue typically appears when the gallery contains a larger number of records.
With a small dataset (e.g., 10–15 rows), virtualization does not aggressively unload rows, so the OnChange event works correctly — even when scrolling.
However, with larger datasets, virtualization becomes more active, and this edge case becomes reproducible.

Recommended
Instead of patching data directly inside OnChange, a safer and more scalable approach is:

Allow users to edit values inside the gallery.

Commit all changes via a Save button.

This avoids:

Missed OnChange events

Excessive API calls when patching on every edit

Performance concerns with larger datasets

Example Save Button Logic
ForAll(

    Gallery1.AllItems As g,

    Patch(

        TestData,

        LookUp(TestData, ID = g.ID),

        {

            Name: g.txtName.Text

        }

    )

);

Notify("Saved successfully", NotificationType.Success)

What this does:

Iterates through all visible gallery rows (Gallery1.AllItems)

Uses alias g to safely reference each row

Reads the current textbox value (g.txtName.Text)

Updates the data source in one controlled operation

Result
Using this Save button logic, I was able to:

Modify multiple records (e.g., first and tenth record)

Scroll through the gallery

Save successfully without missing updates

This approach is more suitable as compared to relying on OnChange inside a virtualized gallery.

Hope this helps.

Thanks!

Inogic

Was this reply helpful? Yes No
Suggested answer

CU24021301-0 2 on at

Like
a
(0)

Report
Copy link

Link copied!

Thanks for the confirmation on gallery virtualization, I suspected something along those lines.

Interestingly, your suggested approach of using For all to iterate through Gallery.AllItems was my initial implementation. However, I found that with large galleries (25+ rows), the ForAll would still sometimes miss out some of the upper gallery rows when scrolled to the bottom. Scrolling back up to the top would sometimes work, but it seemed inconsistent.

As a workaround, I have stuck with using the OnChange property with Patch for now, but have changed my Text Input from the "Classic" to the "Modern" version. This enables setting the Trigger output property to Keypress, so user inputs are captured instantaneously, i.e. before the user can scroll away (works ok for my Use Case as the inputs are small numbers, but might cause issues with longer numbers/strings repeatedly firing OnChange as the user types)

Was this reply helpful? Yes No