Task

Create a custom (PCF) control for use in edit form of a model-driven app which would add a simple, display-only, visual indicator based on the current state of the entity.

Problem

After following the steps to create the control, implement the requirements, test it in the browser test harness and publish it, I struggled to make it appear in Components list of form editor. After doing pac pcf push, it would appear in the list of custom controls in the default solution of the environment, but I could not make it available for adding to the form itself.

All sources on the internet, including official documentation, were pointing to classic form editor and changing the default control for a field. Since the task was to display additional data and not replace default input control, this felt unnecessary. Nevertheless, I tried to follow the steps but Field Properties dialog would not show. Classic editor appears to be very unstable.

Experimenting with different way of publishing by using msbuild to create unmanaged (and then managed) solution and manually import it did not lead to success.

Using search engines and AI chat did not help.

Idea

After a couple of days, I got back to this and thought - what if I tried to publish a sample control from the samples repository?

That worked. After doing all steps - the control showed in the form editor.

OK, now, what is different between that control and my control? Can’t see anything obvious: directory structure is the same, manifest looks the same, implementation follows the same pattern.

Then, let’s try and apply changes from my control to sample control step by step and see at which point it stops showing up in the form editor.

Resolution

Doing that demonstrated that once usage attribute of property elements in manifest is changed to input, control is no longer displayed in the Components tolbox of the form editor.

And remember, the goal was to enrich the display of data, not to edit it, and so it seemed logical to select input value. So easy to make a mistake costing many hours.

But how is one to know in the first place? Here’s the relevant excerpt from the documentation:

Name:           usage
Type:           bound, input or output
Description:    The usage property identifies if the property is meant to represent a column that the component can change (bound), read-only (input) or output values

Neither here nor elsewhere did I found it stated that properties must be bound for the control to work.

After the fact, searching with appropriate keywords produced some results from which it can be understood that other people are seeing same behavior.

Bonus funny moment

At one point I found a post by a developer saying he is coming from C++ background. He needs to do something with Power Apps but wonders where is all the documentation - all he can find is videos. I felt his pain :)

Takeaway

Do things in tiny steps. Especially so if the platform is new to you.

While working on a new feature for our app, I needed to add notifications. Copy and paste being developer’s best friends, I duly copy/pasted notifications for some other feature and went about adjusting the code. The plan was to display notifications as ongoing for a while so that they can’t be dismissed and then remove the ongoing flag to convert them to dismissible notifications. Everything worked without a hitch, except for the minor detail - Clear button in the notification shade which usually dismisses all notifications (bar ongoing ones) was not clearing these notifications. I could manually dismiss, but Clear would not remove them. After commenting out everything that could be commented out, after looking (in vain) into documentation, a thought occurred that too much may have been removed. Looking at the other feature’s notifications code I noticed that they are grouped.

And sure enough, after a group was assigned to notifications, Clear started working again.

This was not reproduced in sample app. However, in production app the issue and solution were real and reproducible. Possible explanation could be that in production app notifications transition thru several stages, while sample app was simpler.

What’s depressing here is that these things are not documented. Maybe this is explained somewhere, but after checking many notifications related pages in the docs, I was unable to find the rationale for the observed behavior.