If I make a change in design-mode to a form that has a DropDownList or an UltracomboEditor, I'm seeing a strange error. I'm trying to add a button -- the change I'm making to the form shouldn't affect the dropdown at all, but it does. It looks like when the .resx file is getting recreated, it somehow adds the wrong value. After the change, the form won't compile, and VS won't even let me reopen the form. Full text of the error is below. In the .Resx File:
<data name="ValueListItem24.DataValue" mimetype="application/x-microsoft.net.object.binary.base64"> <value> AAEAAAD/////AQAAAAAAAAAEAQAAAB9TeXN0ZW0uVW5pdHlTZXJpYWxpemF0aW9uSG9sZGVyAwAAAARE YXRhCVVuaXR5VHlwZQxBc3NlbWJseU5hbWUBAAEICgIAAAAGAgAAAAAL </value> </data>
becomes
<data name="ValueListItem24.DataValue" mimetype="application/x-microsoft.net.object.binary.base64">
<value> AAEAAAD/////AQAAAAAAAAAEAQAAAA1TeXN0ZW0uREJOdWxsAwAAAAREYXRhCVVuaXR5VHlwZQxBc3Nl bWJseU5hbWUBAAEICgIAAAAGAgAAAAAL</value>
Error 138 TargetInvocationException: Type in the data at line 1046, position 5, cannot be loaded because it threw the following exception during construction: Only one DBNull instance may exist, and calls to DBNull deserialization methods are not allowed.
at System.Resources.ResXResourceReader.ParseXml(XmlTextReader reader)
at System.Resources.ResXResourceReader.EnsureResData()
at System.Resources.ResXResourceReader.GetEnumerator()
at Microsoft.Build.Tasks.ProcessResourceFiles.ReadResources(ReaderInfo readerInfo, IResourceReader reader, String fileName)
at Microsoft.Build.Tasks.ProcessResourceFiles.ReadResources(String filename, Boolean shouldUseSourcePath)
at Microsoft.Build.Tasks.ProcessResourceFiles.ProcessFile(String inFile, String outFileOrDir)
XmlException: Type in the data at line 1046, position 5, cannot be loaded because it threw the following exception during construction: Only one DBNull instance may exist, and calls to DBNull deserialization methods are not allowed. Line 1046, position 5.
NotSupportedException: Only one DBNull instance may exist, and calls to DBNull deserialization methods are not allowed.
at System.DBNull..ctor(SerializationInfo info, StreamingContext context)
Thanks,
Brad Larsen
Stratis Business Systems, Inc.
Same happened to me, It was a Datetimepicker with a null value (Property Allow Null = True )
I decided to set the date as you mention, but then to set the property to allow null = False at RUN TIME only, that was the trick.
This because everytime I moved any other child object in the form gave as a result the same error again, but when the Datetimepicker had a date everything worked fine. This works.
Thanks!
I ran into a similar issue with the UltraCalendarCombo control. To mitigate the issue, this is what I did:
When I followed these steps and examined the new .resx file that was generated after saving, all of the entries pertaining to the value of the UltraCalendarCombo controls had been removed and the form continued to open successfully.
I don't know if this solution can be adapted to your problem, but maybe it will give you an idea.
Hi Brad,
Microsoft closed the issue because they said they were unable to duplicate it. I'm not sure why that is, though. It's very easy to duplicate. All you need is a control that returns DBNull from a property at design-time.
In my experience, though, once they close an issue, any further updates to it are ignored - at least, I've never gotten a response to any such feedback. So the only option I can see would be to submit a new issue to Microsoft with a sample project demonstrating the issue.
Regarding your workaround, it seems like that should work, but isn't that kind've a pain having to do that every time you open the form designer? It seems to me that it would be easier to simply change the DataValue of the ValueListItem to null (or some other value) at design-time. And then in code, change that DataValue to DBNull.Value at run-time. Then you never have to worry about it again.
Hello Brad,
Yes, if your able to overwrite the value then that seems to what you are looking for. Please let me know if you have any additional quesitons as well.
Yes, I suppose we can use that workaround. It's a shame that such a basic .Net feature isn't working. That issue is closed on Microsoft's site, so it looks like they are not going to fix it either.
The workaround we have been using is just undo-ing the change. I manually take the value for DBNULL from history and overwrite the incorrectly serialized one. Seems to work. I assume you'd consider that a valid workaround as well, right?