nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Silverlight API 2.2 -- Not Detecting changes in FeatureDataForm

WilliamKimrey

Hello everybody,

I just installed the 2.2 API this morning and was testing an application when I noticed that some of my editing was not being saved. They were working fine before the new API, but I can't figure out why only some of my features are not working when others are working just fine.

Here's what happens:

After making an edit to a feature in a FeatureDataForm, usually the "Apply" button is enabled to allow me to applychanges before I save. Now, on some of my FeatureLayers, when I make a change, the "Apply" button never enables and when I hit save, the changes are not saved.

This only happens on a few of my Layers, but I can't figure out what they have in common. It's not dependant on the Geometry type, nor is it dependant on the way the FeatureLayer is rendered in application. It affects versioned and versioned with moves to base equally. It also affects features that do and do not have GlobalIDs.

Even if I try to have the FeatureDataForm apply changes programmatically, it still does not recognize it. What am I missing?

Thanks,
Will

Vind meer berichten getagd met

Accepted answers

All comments

MattPratap

I am also having this problem.

We are aware of this bug and plan on having it fixed in our next release.

When do you think the next release will be available?

ChristopherHill

I'm running into this issue also.

I have 8 Coded Domain Values all allowing null values. One is the code for the symbology so I set it via code. I enter data into a text box and the apply button enables until the textbox loses focus. Then no matter how many data fields I set I cannot get the Apply button to enable again.

This worked in 2.1 but as soon as I switched to 2.2 this becames an issue.

There are a couple of new features added in 2.2. Support for FeatureTypes and DynamicCodedValueDomains aka SubDomains as ComboBoxes, these new additions introduced a bug. We are aware of this bug and plan on having it fixed in our next release. The FeatureDataForm is part of our open source toolkit on codeplex. You can modify the source code to make it work or you can replace the 2.2 source with the 2.1 source as a workaround.

HyrumErnstrom

I'm running into this issue also.

I have 8 Coded Domain Values all allowing null values. One is the code for the symbology so I set it via code. I enter data into a text box and the apply button enables until the textbox loses focus. Then no matter how many data fields I set I cannot get the Apply button to enable again.

This worked in 2.1 but as soon as I switched to 2.2 this becames an issue.

WilliamKimrey

This is not the case.

This situation is what I thought was happening at first, but I have come to realize that it happening regardless of the TypeIDField.

Example:

TypeIDField = "TYPE"
GraphicSource.Attributes["TYPE"] = "Overhead Sign";
GraphicSource.Attributes["Street1"] = null;
GraphicSource.Attributes["Street2"] = null;
GraphicSource.Attributes["DateInstalled"] = null;

DateInstalled is the only attribute that is not using a Coded Value Domain. TYPE has its own domain and the two Street attributes share a domain.

If both streets already have a value, I can edit the DateInstalled just fine. If either of them is null, or if I create a new sign that has no streets assigned yet (so null in both fields), then I can not make an edit because the FeatureDataForm will not let me apply changes.

ChristopherHill

Let me clairfy,

if the "FeatureDataForm.FeatureLayer.LayerInfo.TypeIDField = "MyField" and the attribute on the graphic GraphicSource.Attributes["MyField"] == null <-- this makes the FeatureDataForm not work.

WilliamKimrey

Just to make sure, when you say TypeIDField, you mean "FeatureDataForm.FeatureLayer.LayerInfo.TypeIDField"? If so, then this is not my problem.

I have some FeatureLayers where this happens, but I have more FeatureLayers where the TypeIDField is set and I am still having this problem.

In testing for this, I did notice this functionality. Regardless of whether or not I have a TypeIDField, when I edit any attribute that is not a ComboBox, the Apply Button enables while I'm editing that attribute. As soon as I move to a different attribute, the Apply Button disables. This tells me that it's something happening during the FeatureDateForm.LostFocus event. (but I could be mistaken).

ChristopherHill

We recently added support for TypeID Field as a combo box. I was able to reproduce that If the typeIDField value = null then the editing functionallity for the FeatureDataForm is not updating. Can you confirm that it is indeed the TypeIDField that is causing your problem.

WilliamKimrey

Bryan,

Thanks so much for the insight. You're right, it was the null in the coded value domain field that was causing the error. I had to go back into ArcMap, assign a value, and then it worked in the FeatureDataForm.

This is a problem for me because I have 15 FeatureLayers in this editor with varying numbers of coded value domains and lots of old features that existed before the domain and therefore have null values. I can't go through all the data and randomly assign values (because A: I dont' know the correct values, and B: I'm not sure anybody else knows the correct value either).

Another problem with this is the fact that when a feature with a coded value domain is added, if the domain does not have a Default Value (which is common in my case) then this bug affects that feature as well. You'll still be able to create the feature, but you'll only be able to save the attributes that were created with it.

It's looking like I'll have to backpedal to 2.1 for now unless a workaround can be discovered.

Thanks,
Will

BryanBoutz1

I was struggling with that as well and found a solution in my case. It turned out I had a coded value domain field in my feature where some records had a null. I added an unknown value and updated my data to work around the problem.

I traced the problem through the FeatureDataForm code in the toolkit and found that it does a variety of data checks before posting attribute changes. The null value in one of my domain fields was causing a function called Utilities.AreEqual to set a hasError property that eventually just disabled the commit button and stopped further action. It repeated this every time any text changed on the data form.

This is apparently a change from 2.1 as I was getting it to try to make an update, but the REST service would then return a rather unhelpful message, but at least it was something to know there was a problem.

Hopefully that helps, or at least points someone in the right direction.

Doe mee aan het gesprek

Aangemelde leden kunnen berichten plaatsen, updates volgen en meer. Nieuw hier? Registreer een gratis account.

Snelle Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.