-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problem with "empty" control #5
Comments
Hello, |
Hello, Please update your solution to the current version v2.1 |
Thank you for prompt reaction. Item c) is still actual. Built-in multi-line controls will save spaces as is, but if field is mandatory and contains only spaces and new lines, system will treat it as empty and will not allow saving. This is proper behavior. With D365RichTextEditor mandatory field with such content will also contain tags and system will allow saving it as if it's a meaningful data. Can you please make control return null instead? |
Hallo Triangle333, I will fix c) aswell as soon I got some time in the next days. |
Hallo Triangle333, the issue is fixed now, please upgrade to V2.4. Empty strings mixed with html, not mixed with html and in any length are handled as NULL now, |
Thanx! Our Q&A is quite happy now :) |
Given: A field on a form with attached D365RichTextEditor control.
a) Open fresh form and inspect this field value: Xrm.Page.getAttribute( "fieldName").getValue() will return null. So far, so good
b) Enter some text into control and then remove all text. Value returned will be
"<p><br></p>"
. Expected value is nullc) Enter some spaces into control and save. Refresh form (F5) and control will stop showing these spaces but value returned will be still
"<p> </p>"
. Expected value is null because built-in controls trim strings on save. I think that text consisting of only spaces and new lines should be treated (and saved) as null too.Why this is important: I have some validation logic on form that checks if certain fields are filled or not. With built-in controls this is easy, just compare with null. But now we have new unexpected states of data. Can you please make this control to be more compliant with system`s way of saving strings?
The text was updated successfully, but these errors were encountered: