.NET Control Error 1172 - Only in executable

[rfessler]

Hi everyone,

I just ran into an issue this morning after building an executable version of my program, which uses the Actor Framework. It contains a .NET control (version 3.5) on one of my front panels. There's a function that I call to pass some XML strings to the control, which then handles filling in the data. This works just as expected in the development environment, but when I build an executable and run that, the control just sits there without being properly filled in. I attached an error indicator to the invoke node, which is showing me this error:

Error calling method InstrumentDataGridView.InstrumentDataGridView.LabVIEW_FillTableFromXML, (System.ArgumentNullException: Key cannot be null.
Parameter name: key) <append><b>System.ArgumentNullException</b> in Experiment UI.lvlib:Experiment UI Panel.lvclass:Actor Core.vi:1->Actor Framework.lvlib:Actor.lvclass:Actor.vi:4->Actor Framework.lvlib:Actor.lvclass:Actor.vi.ACBRProxyCaller.D140000E

I then ran DebugView to get some more detailed information on what was happening and here's the log that it spit out:

00000006	80.98936462	[3404] Created new AppDomain: ICAS-EPR.exe for Reflection 	
00000007	82.80818939	[3404] Created new AppDomain: ICAS-EPR.exe for Run 	
00000008	85.75064087	[3404] DNError: Error calling method InstrumentDataGridView.InstrumentDataGridView.LabVIEW_NotifyAcquisitionStopped (1172). System.ArgumentNullException: Key cannot be null. 	
00000009	85.75064087	[3404] Parameter name: key	
00000010	85.75064087	[3404]    at System.Collections.Hashtable.get_Item(Object key) 	
00000011	85.75064087	[3404]    at NationalInstruments.LabVIEW.SyncInvokeTable.LookupControl(Object key) 	
00000012	85.75064087	[3404]    at NationalInstruments.LabVIEW.DNRuntime.InvokeMethod(Int32 invokeType, Type type, ObjectId objectId, String methodName, Type[] parameterTypes, Int32[] parameterFlags, ObjectId[]& parameterIds)	
00000013	85.75064087	[3404]  	
00000014	114.37963104	[3404] DNError: Error calling method InstrumentDataGridView.InstrumentDataGridView.LabVIEW_FillTableFromXML (1172). System.ArgumentNullException: Key cannot be null. 	
00000015	114.37963104	[3404] Parameter name: key	
00000016	114.37963104	[3404]    at System.Collections.Hashtable.get_Item(Object key) 	
00000017	114.37963104	[3404]    at NationalInstruments.LabVIEW.SyncInvokeTable.LookupControl(Object key) 	
00000018	114.37963104	[3404]    at NationalInstruments.LabVIEW.DNRuntime.InvokeMethod(Int32 invokeType, Type type, ObjectId objectId, String methodName, Type[] parameterTypes, Int32[] parameterFlags, ObjectId[]& parameterIds)	
00000019	114.37963104	[3404]  	
00000020	133.64822388	[3404] Destroying AppDomain: ICAS-EPR.exe for Reflection 	
00000021	133.68054199	[3404] Destroying AppDomain: ICAS-EPR.exe for Run 	

As you can see, I get a "System.ArgumentNullException: Key cannot be null." error when calling both LabVIEW_NotifyAcquisitionStopped and LabVIEW_FillTableFromXML. Neither of these functions throw that type of exception. I thought that maybe the constructor wasn't being called, but I added some code to the constructor to write to a file and that functioned as expected. Then I wrote a new function that wrote to a file and called that when the VI loaded. That function worked fine and didn't throw any errors. 

I am completely stumped as to why this is happening. Both the development environment and the executable use the exact same DLL code. I appreciate any help I can get!

[tyk007]

While I can't comment on the specific methods you have constructed, the ArgumentNullException type is being thrown by the HashTable collection (see lines 10 and 16) when attempting access the value at the specified index (eg. collection[index] given the use of the internal compiler-generated method get_Item). 

It's not clear whether your control uses a collection internally or not but I am guessing that it doesn't and that the HashTable calls are LabVIEW's internal way of tracking your controls, given the preceeding exception messages for each call indicate LabVIEW attempting to make a runtime method call. If this is the case, then your methods are not being executed as you suggested; the exception is being thrown as LabVIEW has lost a reference to your control methods somehow. When you say that you tried an additional function, I assume you tried this with the built executable, and that the control (a .dll assembly I assume) is added to the build spec and exists in the "data" folder once built.

You could try removing the control and it's container from the Front panel and add it back in again.

If you *are* using collections and have Visual Studio Professional or higher you can attach to the executable and debug into your method calls when execution starts to ascertain why you have a null argument being passed in.

Unfortunately this is a bit hypothetical unless you can provide some more information (LabVIEW version, code, setup, anything) and some more ideas as to how you have your system configured.

[rfessler · Accepted solution]

tyk007, thanks for the reply! 

I ended up solving the problem! I did some testing to see where the function calls fail. I make one call to the test function in a flat sequence structure prior to my event loop, so it runs as soon as the VI is loaded. That call doesn't throw any errors, but if I make another call to it within my event loop, it fails. This got me thinking that something is destroying the reference to the control somewhere in my code. In addition to the test function call that I make in the flat seqeunce structure, I also use an invoke node wired to "This VI" reference to reinitialize all values to their defaults. It turns out that removing that invoke node fixes the problem! Reinitializing all values to default must destroy the reference to the .NET control, which makes all future function calls to the control throw an error. 

Now, is this a bug that I should notify National Instruments about, or is it expected behavior? 

[tyk007]

---

@rfessler wrote:

tyk007, thanks for the reply! 

I ended up solving the problem! I did some testing to see where the function calls fail. I make one call to the test function in a flat sequence structure prior to my event loop, so it runs as soon as the VI is loaded. That call doesn't throw any errors, but if I make another call to it within my event loop, it fails. This got me thinking that something is destroying the reference to the control somewhere in my code. In addition to the test function call that I make in the flat seqeunce structure, I also use an invoke node wired to "This VI" reference to reinitialize all values to their defaults. It turns out that removing that invoke node fixes the problem! Reinitializing all values to default must destroy the reference to the .NET control, which makes all future function calls to the control throw an error. 

Now, is this a bug that I should notify National Instruments about, or is it expected behavior? 

---

I'm glad you found a solution to your problem!

I would say that this probably falls under the category of "bug", simply on the basis of the unusual error you reported that indirecftly indicates the issue. In the case you describe, I would have expected that either:

• The control reference was destroyed and re-created (possible giving you unusal data due to the state of the object now being new, but still a new valid reference none the less)
• LabVIEW would not re-create the reference but would indicate that the control reference was invalid rather than exposing the internal implementation of the control management to the user.

I'd file this with your local NI representative. Please feel free to post a CAR number here and update us once you know more about how/when this will be resolved.

[Charles_CLA]

The default value of a .NET control is not a refnum. Therefore I would say this is behaving exactly as expected and not a bug.

[tyk007]

---

@Charles_CLA wrote:

The default value of a .NET control is not a refnum. Therefore I would say this is behaving exactly as expected and not a bug.

---

Very interesting, thanks for responding. I would not have expected an internal and virtually unintelligible exception bubbling up from the bowels of LabVIEW .net control management to be the intended behaviour of this action; this would be a clear usability failure - the response LabVIEW gives under this scenario I would consider a bug. I would still encourage the original poster to contact their NI representative in the hope that this improves the usbaility of this feature over time.

[Charles_CLA]

---

@tyk007 wrote:

---

@Charles_CLA wrote:

The default value of a .NET control is not a refnum. Therefore I would say this is behaving exactly as expected and not a bug.

---

Very interesting, thanks for responding. I would not have expected an internal and virtually unintelligible exception bubbling up from the bowels of LabVIEW .net control management to be the intended behaviour of this action; this would be a clear usability failure - the response LabVIEW gives under this scenario I would consider a bug. I would still encourage the original poster to contact their NI representative in the hope that this improves the usbaility of this feature over time.

---

The error message couldn't be more clear (and it is .NET giving the message to LabVIEW for the record, you would see the same message if you did this in Visual Studio). The key cannot be null (default value). The .NET control is a reference, if you set it to null you can no longer expect to talk to that control. This is the exact same behavior you would get if you have a reference to a LabVIEW control, or a queue control, notifier etc... if you blank the value of the reference you can no longer talk to the object. Why do you want LabVIEW to automatically know that you want to initialize every control to default value except a .NET control? 

[rfessler]

---

@tyk007 wrote:

---

@Charles_CLA wrote:

The default value of a .NET control is not a refnum. Therefore I would say this is behaving exactly as expected and not a bug.

---

Very interesting, thanks for responding. I would not have expected an internal and virtually unintelligible exception bubbling up from the bowels of LabVIEW .net control management to be the intended behaviour of this action; this would be a clear usability failure - the response LabVIEW gives under this scenario I would consider a bug. I would still encourage the original poster to contact their NI representative in the hope that this improves the usbaility of this feature over time.

---

I would also not expect this to be the correct behavior, especially since I only encountered the issue when I've built the application. I would suspect making a call to "Reinitialize to Default Values" would throw away the .NET control object and recall the constructor, if anything. I would not expect for future calls to the control to throw an error coming from internal LabVIEW code indicating that it cannot find the control.

I sent in a service request an hour or so ago. I will update this thread with what I find out!

[rfessler]

I was told the CAR number is 220435.