cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
DianaBirkelbach
Most Valuable Professional
Most Valuable Professional

Which event for notifyOutputChanged

When we have a Textarea PCF control, we can call notifyOutputChanged on the events: "input" or "change" . What's the best practice for that?

If we choose "input", the control will trigger it's own updateView() for every character we type; it doesn't seem to be a good way.

If we choose "change", it will call the notifyOutputChanged only if the textarea looses focus, but when the autosave is triggered before the user leaves the input, the updateView() will be triggered with a old value, and he looses the text he typed.

Kind regards,
Diana
----------
Please click "Accept as Solution" if my post answered your question so that others may find it more quickly. If you found this post helpful consider giving it a "Thumbs Up."
13 REPLIES 13
ben-thompson
Memorable Member
Memorable Member

I've just checked what I do in one of the textarea controls I have and it's called on mouse leave.

 

It's probably worth saying that we don't use a textarea input control, instead we use an editable div which we set to contentEditable=true onMouseEnter and to false when onMouseLeave at which point we also call notifyOutputChanged

---
If this post has answered your question please consider it for "Accept as Solution" or if it has been helpful give it a "Thumbs Up".

Thank you @ben-thompson for the fast answer.

But if I understand right, you must have the same problem.

To reproduce it, edit another field on the form, just to get the form dirty, then start to edit in your div, and don't leave the div, just wait for the autosave. Then the content edited will be deleted, because the updateView() is called with the old value.

In updateView we have to change the value of the input, because somebody else might have changed the value using the from sdk (outside the control, using attribute.setValue()), so we have to reflect this change.

A workarround would be to check in updateView() to see if the value that we get is different than the last values that we set in getOutputs(), but that's not really right, since somebody might really want to change the value back, using the attribute.setValue().

So it seems to me that we are forced to report every change instantly by calling notifyOutputChanged, which will call again the updateView() method. 

I'm not sure if I can explain what happens. I'll attach a short video about this issue. 

 

Kind regards,
Diana
----------
Please click "Accept as Solution" if my post answered your question so that others may find it more quickly. If you found this post helpful consider giving it a "Thumbs Up."

In which case I can't help

 

I'm using a recentish environment (created this month but not upgraded to wave 1) and autosave is enabled but I can't reproduce the issue as the autosave functionality doesn't seem to be working.  Granted the form does contain 4 different PCF controls but I don't think any of those are the issue. 

 

Now I would be concerned by that but in April the save button appears so the interface is better.

 

---
If this post has answered your question please consider it for "Accept as Solution" or if it has been helpful give it a "Thumbs Up".

Scrap that I left it open for 5 minutes and it did autosave without losing data - so I wonder if the issue is that you are using a textarea which is an input field and we use editable Divs with the value stored in the background in a javascript variable.

 

Looking at the updateview routine we have - we store the raw parameter value in a separate variable and check it every time the routine is called - if the value changes we update the text within the Div otherwise we leave it as is.

---
If this post has answered your question please consider it for "Accept as Solution" or if it has been helpful give it a "Thumbs Up".

Thanks @ben-thompson ! It's a awesome community here! 

Lucky you that it works! 😉 

But then you implemented already one of the workarrounds: you check if the value is a new one, and if it's the value that you already knew, you ignore that: so you ignore the refresh after the autosave.

That would work in most of the cases, but there could happen that the form scripting is calling attribute.setValue(oldValue) in the meanwhile. You would ignore that, right? I agree that won't happen a lot (maybe never), but maybe a plugin sets the value back, and you'll ignore it.  🤔 

 

In case it helps somebody else, I have now an implementation using an "input" event (to save internal the value), and there I debounce the "notifyOutputChanged" (so it will trigger only once in 250 ms). 

 

Seems that both solutions are workarrounds. 

 

 

Kind regards,
Diana
----------
Please click "Accept as Solution" if my post answered your question so that others may find it more quickly. If you found this post helpful consider giving it a "Thumbs Up."

To be honest my viewpoint is that autosave is more trouble than it's worth - come April I will be doing everything I can to disable it..

 

What I care about is that the user interface works the way users would expect it to which means that the form should be displaying exactly what the user expects. So the only time we would update a field within the PCF control is if another control on the form triggered. 

 

For a lot of our cases that's easy as we are using PCF controls to avoid on page scripting - say field 2 is an (attribute list) attached to field 1 (entity list) so when field 1 changes we reset field 2 and update the options to reflect that change but outside of that you really should be ignoring any value changes - the logic really should be set value on first pass of updateview and ignore that part of the code on subsequent runs. 

---
If this post has answered your question please consider it for "Accept as Solution" or if it has been helpful give it a "Thumbs Up".

Thanks again @ben-thompson . You're right. Actually registering on "input" doesn't work as I thought, since between the autosave start and the moment the form is refreshed, there are a few milliseconds, while the user is typing, so he would lose some chars.

 

I'll use the workarround  you suggested:  I register on "change" of the input, and in updateView() I ignore the value if it's the old one. So using this workarround the value is not lost after autosave, but it's still not saved until the user change the focus outside the control. So if another script on the form is navigating away or closing the window, the user loses the introduced text.
But I've checked: an out-of-the-box control doesn't their values, they automatically save it somehow. Since I have no influence on the other scripts in the form, I have to be sure that I don't lose the introduced data .

 

I've made a test by defining in the console the following function (it only saves the form if necessary, and closes the form). I try to simulate another scripts running on the form:

function checkSavingOnLeave(fieldName){
 const value = Xrm.Page.getAttribute(fieldName).getValue();
 console.log(`value at start: ${value}`);
 window.setTimeout( async () => {
    console.log(Xrm.Page.getAttribute(fieldName).getValue());
    console.log(`dirty: ${Xrm.Page.data.getIsDirty()}`);
    const saved = !Xrm.Page.data.getIsDirty() || await Xrm.Page.data.save();
    if(saved===true) {
      console.log(`value before close: ${Xrm.Page.getAttribute(fieldName).getValue()}`);
      Xrm.Page.ui.close();
    }
    else
       console.log("not saved");
 }, 7000);
}

 So I call the function for my pcf control (while the form is not dirty) then I go to my PCF control and I change the text, but don't leave the control for a few seconds, until my script is triggered.

I get this console output:

checkSavingOnLeave("orb_textarea")
value at start: PCF
PCF
dirty: false
value before close: PCF

The form didn't get the change, it gets closed, but the text I typed is lost.

 

If I call the same function for a standard input control (like the name control) I get the same log

checkSavingOnLeave("orb_name")
value at start: PCF
PCF
dirty: false
value before close: PCF

The difference is that the orb_name (which is a standard control) doesn't loose the changed text, even if the value after the Xrm.Page.data.save() is still the old one, while my PCF control loses the changed text.

 

Here is my updateView(), in case I do something wrong:

	public updateView(context: ComponentFramework.Context<IInputs>): void
	{						
		const maybeNewValue = context.parameters.myTextarea.raw || "";		
		if(maybeNewValue!== this.value){
			this._inputWindowElement.value = maybeNewValue;	
			this.value = maybeNewValue;			
			console.log(`value set to ${maybeNewValue}`);
		}
		this._inputWindowElement.disabled = context.mode.isControlDisabled;		
	}

 

This is not a problem related only to textarea, it happens also with a text input.
It's a very simple example of PCF control: just an input control, nothing fancy. Since the standard controls are made using the same framework, Microsoft must have a solution for that already. Maybe somebody from the team can help me...

 

 

 

 

Kind regards,
Diana
----------
Please click "Accept as Solution" if my post answered your question so that others may find it more quickly. If you found this post helpful consider giving it a "Thumbs Up."

Thanks for the inputs and great discussion on this.

 

I reached out to the engineering team and we have some investigations done. We are evaluating whats the best way to handle this from UCI and form/PCF infra perspective.

 

One item which we are looking into is to NOT call update on the control via auto-save if the value for that control has not change (tracked by internal bug id 1739331).  Will keep this thread posted on updates.

 

Hemant Gaur

Thank you very much to all who are helping us. Is a great community.

 @HemantG  Yes, would be great to have this solution: not to call updateView after auto-save.

I just tried my PCF control in a CanvasApp, and the solution that I thought it worked in Model-Driven apps (use the onInput event, so basically only when the user leaves the input) doesn't work in CanvasApps. There we have to implement a Patch requests (since it cannot be integrated in the EditForm-Submit process), and the moment the user clicks the Save Button, the "input" event was not  triggered already (if the user goes directly from the input to the save button), and he loses the data.

So the solution you and the engineers figured out, might be the only way if we want the control to work both in model-driven and canvas apps.

Best regards,

Diana

Kind regards,
Diana
----------
Please click "Accept as Solution" if my post answered your question so that others may find it more quickly. If you found this post helpful consider giving it a "Thumbs Up."

Helpful resources

Announcements

Community will be READ ONLY July 16th, 5p PDT -July 22nd

Dear Community Members,   We'd like to let you know of an upcoming change to the community platform: starting July 16th, the platform will transition to a READ ONLY mode until July 22nd.   During this period, members will not be able to Kudo, Comment, or Reply to any posts.   On July 22nd, please be on the lookout for a message sent to the email address registered on your community profile. This email is crucial as it will contain your unique code and link to register for the new platform encompassing all of the communities.   What to Expect in the New Community: A more unified experience where all products, including Power Apps, Power Automate, Copilot Studio, and Power Pages, will be accessible from one community.Community Blogs that you can syndicate and link to for automatic updates. We appreciate your understanding and cooperation during this transition. Stay tuned for the exciting new features and a seamless community experience ahead!

Summer of Solutions | Week 4 Results | Results posted on July 24th

We are excited to announce the Summer of Solutions Challenge!   This challenge is kicking off on Monday, June 17th and will run for (4) weeks.  The challenge is open to all Power Platform (Power Apps, Power Automate, Copilot Studio & Power Pages) community members. We invite you to participate in a quest to provide solutions in the Forums to as many questions as you can. Answers can be provided in all the communities.    Entry Period: This Challenge will consist of four weekly Entry Periods as follows (each an “Entry Period”)   - 12:00 a.m. PT on June 17, 2024 – 11:59 p.m. PT on June 23, 2024 - 12:00 a.m. PT on June 24, 2024 – 11:59 p.m. PT on June 30, 2024 - 12:00 a.m. PT on July 1, 2024 – 11:59 p.m. PT on July 7, 2024 - 12:00 a.m. PT on July 8, 2024 – 11:59 p.m. PT on July 14, 2024   Entries will be eligible for the Entry Period in which they are received and will not carryover to subsequent weekly entry periods.  You must enter into each weekly Entry Period separately.   How to Enter: We invite you to participate in a quest to provide "Accepted Solutions" to as many questions as you can. Answers can be provided in all the communities. Users must provide a solution which can be an “Accepted Solution” in the Forums in all of the communities and there are no limits to the number of “Accepted Solutions” that a member can provide for entries in this challenge, but each entry must be substantially unique and different.    Winner Selection and Prizes: At the end of each week, we will list the top ten (10) Community users which will consist of: 5 Community Members & 5 Super Users and they will advance to the final drawing. We will post each week in the News & Announcements the top 10 Solution providers.  At the end of the challenge, we will add all of the top 10 weekly names and enter them into a random drawing.  Then we will randomly select ten (10) winners (5 Community Members & 5 Super Users) from among all eligible entrants received across all weekly Entry Periods to receive the prize listed below. If a winner declines, we will draw again at random for the next winner.  A user will only be able to win once overall. If they are drawn multiple times, another user will be drawn at random.  Individuals will be contacted before the announcement with the opportunity to claim or deny the prize.  Once all of the winners have been notified, we will post in the News & Announcements of each community with the list of winners.   Each winner will receive one (1) Pass to the Power Platform Conference in Las Vegas, Sep. 18-20, 2024 ($1800 value). NOTE: Prize is for conference attendance only and any other costs such as airfare, lodging, transportation, and food are the sole responsibility of the winner. Tickets are not transferable to any other party or to next year’s event.   ** PLEASE SEE THE ATTACHED RULES for this CHALLENGE**   Week 1 Results: Congratulations to the Week 1 qualifiers, you are being entered in the random drawing that will take place at the end of the challenge. Community MembersNumber of SolutionsSuper UsersNumber of Solutions @anandm08  23 @WarrenBelz  31 @DBO_DV  10 @Amik  19 AmínAA 6 @mmbr1606  12 @rzuber  4 @happyume  7 @Giraldoj  3@ANB 6 (tie)   @SpongYe  6 (tie)     Week 2 Results: Congratulations to the Week 2 qualifiers, you are being entered in the random drawing that will take place at the end of the challenge. Community MembersSolutionsSuper UsersSolutions @anandm08  10@WarrenBelz 25 @DBO_DV  6@mmbr1606 14 @AmínAA 4 @Amik  12 @royg  3 @ANB  10 @AllanDeCastro  2 @SunilPashikanti  5 @Michaelfp  2 @FLMike  5 @eduardo_izzo  2   Meekou 2   @rzuber  2   @Velegandla  2     @PowerPlatform-P  2   @Micaiah  2     Week 3 Results: Congratulations to the Week 3 qualifiers, you are being entered in the random drawing that will take place at the end of the challenge.   Week 3:Community MembersSolutionsSuper UsersSolutionsPower Apps anandm0861WarrenBelz86DBO_DV25Amik66Michaelfp13mmbr160647Giraldoj13FLMike31AmínAA13SpongYe27     Week 4 Results: Congratulations to the Week 4 qualifiers, you are being entered in the random drawing that will take place at the end of the challenge.   Week 4:Community MembersSolutionsSuper UsersSolutionsPower Apps DBO-DV21WarranBelz26Giraldoj7mmbr160618Muzammmil_0695067Amik14samfawzi_acml6FLMike12tzuber6ANB8   SunilPashikanti8

Check Out | 2024 Release Wave 2 Plans for Microsoft Dynamics 365 and Microsoft Power Platform

On July 16, 2024, we published the 2024 release wave 2 plans for Microsoft Dynamics 365 and Microsoft Power Platform. These plans are a compilation of the new capabilities planned to be released between October 2024 to March 2025. This release introduces a wealth of new features designed to enhance customer understanding and improve overall user experience, showcasing our dedication to driving digital transformation for our customers and partners.    The upcoming wave is centered around utilizing advanced AI and Microsoft Copilot technologies to enhance user productivity and streamline operations across diverse business applications. These enhancements include intelligent automation, AI-powered insights, and immersive user experiences that are designed to break down barriers between data, insights, and individuals. Watch a summary of the release highlights.    Discover the latest features that empower organizations to operate more efficiently and adaptively. From AI-driven sales insights and customer service enhancements to predictive analytics in supply chain management and autonomous financial processes, the new capabilities enable businesses to proactively address challenges and capitalize on opportunities.    

Updates to Transitions in the Power Platform Communities

We're embarking on a journey to enhance your experience by transitioning to a new community platform. Our team has been diligently working to create a fresh community site, leveraging the very Dynamics 365 and Power Platform tools our community advocates for.  We started this journey with transitioning Copilot Studio forums and blogs in June. The move marks the beginning of a new chapter, and we're eager for you to be a part of it. The rest of the Power Platform product sites will be moving over this summer.   Stay tuned for more updates as we get closer to the launch. We can't wait to welcome you to our new community space, designed with you in mind. Let's connect, learn, and grow together.   Here's to new beginnings and endless possibilities!   If you have any questions, observations or concerns throughout this process please go to https://aka.ms/PPCommSupport.   To stay up to date on the latest details of this migration and other important Community updates subscribe to our News and Announcements forums: Copilot Studio, Power Apps, Power Automate, Power Pages

Top Solution Authors
Users online (2,760)