Select to view content in your preferred language

Attribute window sometimes freezes and doesn't let me enter data

1379
13
04-12-2011 03:25 PM
MattMiley
Deactivated User
I am using the editor widget and my editor template is pretty big, its got a date picker and 4 drop down choosers and a bunch of empty fields for text only, if I tab through it it works pretty nicely, but if i click each box sometimes it just freezes up and doesn't let me enter any data and it wont let me do anything for like a minute or too, then it lets me click the close only.

Has anyone experienced anything like this?

I think it could be a internet connection problem, cuz when I work on it from my office that is VPNed into the gis server it would happen whenever the vpn looses connection temporarily it freezes like that. But it did the same thing when i was at the server's domian and not using the VPN, so im not sure whats going on.
0 Kudos
13 Replies
JenniferNery
Esri Regular Contributor
I have not seen this happen. If it were network-related issue, you can check for NetworkInterface.GetIsNetworkAvailable() http://msdn.microsoft.com/en-us/library/system.net.networkinformation.networkinterface.getisnetworka....
0 Kudos
WilliamKimrey
Emerging Contributor
I am getting this same behavior.  The Attribute Editor for my EditorWidget is freezing up on me and locking down the application.  This tends to happen when I try to edit attributes quickly, but that's not always the case.

My Attribute Window isn't very large, but I do have several fields that are connected to large domains. (i.e. a list of all valid street names in the city)  However, it still freezes sometimes when I'm not editing those fields.

Here's my basic setup:  I've got a tiled basemap, the Infrastructure Map Service (Dynamic), and a Feature Layer for every feature class in the Infrastructure Map Service (there are 15 total).  The Feature Layers default Where Clause is "OBJECTID = 0" to prevent them from all drawing while zoomed out.  Instead, the Map Service is used to show the features.  After zooming in close enough, (in this case, a resolution of 5.0) the Map Service turns off and the Feature Layers turn on.  I also have a ComboBox that contains a list of the Feature Layers.  None of the Feature Layers are visible until I select one from the ComboBox, then that FeatureLayer's Where Clause is set to "REMOVED IS NULL" (REMOVED is an attribute that we populate instead of deleting so we can recover accidentally 'deleted' data).

Other than that, it's pretty much exactly the same as the first sample for the EditorWidget.  I've checked the log files and added every event handler I could find and none of them can explain what's going on or why the Attribute Editor is freezing up.
0 Kudos
WilliamKimrey
Emerging Contributor
Update:

I've been able to narrow down how the FeatureDataForm freezes when trying to edit attributes.

When a user clicks on the FeatureDataForm outside of the textboxes/datepickers/comboboxes (i.e. clicking on the labels or the whitespace) the GotFocus event fires and sets the focus on the first attribute in the form.

Here's the trick.  If the first attribute has a domain attached to it (so it's a combobox in the form), the freeze occurs.  It doesn't matter how many values are in the domain (i've gotten the freeze to occur with 2 values in a domain).

So, any ideas/suggestions/comments on how to get around this?  My current idea is to rearrange the attributes order so that the first attribute is not a domained attribute, but changing the order of attributes is not the easiest thing to do. 

Help? Anybody?
0 Kudos
ChristopherHill
Deactivated User
@Wkimrey

Is this still the case when working with the EditorWidget and FeatureDataForm or were you able to produce this error with just the FeatureDataForm?
0 Kudos
JenniferNery
Esri Regular Contributor
What version of the API are you using?

From what I understand, you are using this SDK sample: http://help.arcgis.com/en/webapi/silverlight/samples/start.htm#ToolkitEditorWidget
with a FeatureLayer which first field is a coded-value domain, such as this service: http://sampleserver3.arcgisonline.com/ArcGIS/rest/services/HomelandSecurity/operations/FeatureServer....

Are you able to reproduce the issue with this service? Can you share with us the steps to reproduce? Did you show the FeatureDataForm as a result of adding a new feature or by clicking on DisplayAttributes button and then selecting a feature? How was your FeatureLayer set up ?(Mode, AutoSave, etc.) If you had only FeatureDataForm, without going through EditorWidget, do you still have this issue (like in this sample: http://help.arcgis.com/en/webapi/silverlight/samples/start.htm#ToolkitFeatureDataForm)?

I apologize I have more questions.. I could not reproduce it and maybe I am missing steps. I have tried selecting label of the first field but I form does not freeze on me.
0 Kudos
WilliamKimrey
Emerging Contributor
The problem is just with the FeatureDataForm.

I've found that this is a known bug with the FeatureDataForm. (NIM063509)

Basically, when the FeatureDataForm tries to edit an attribute that is both a domain value and is the value that the layer uses for rendering different symbologies, the freeze occurs.

I've also learned that this bug has been fixed in the Silverlight API 2.2 Beta, but sadly, that is not an acceptable solution for me since I can't install a Beta product onto our web server.  Unless there's something else that comes up, I'll have to wait for the official 2.2 release.
0 Kudos
WilliamKimrey
Emerging Contributor
@jenniferdnery

I"m using 2.1 version of the API (build 446)

I've been able to reproduce this error both when I add a new feature and when I select an existing one.  I'm not using the "DisplayAttributes" button.  Instead, I'm getting the graphic and setting the GraphicSource of the FeatureDataForm in the code-behind.

Here's the setup for my FeatureLayers

DiableClientCaching = true
AutoSave = false
OutFields = "*"
Mode = OnDemand
0 Kudos
by Anonymous User
Not applicable
Is there any indicators from ESRI when this issue (NIM063509) will be fixed?  Brad
0 Kudos
JenniferNery
Esri Regular Contributor
This bug has been marked fixed prior to v2.2 release.
0 Kudos