.NET container and Xceed control puts LabVIEW in bad state

[Gaulinmp]

I am using Xceed Grid to display a more flexible UI in LabVIEW. I wrote a wrapper DLL to call the Xceed DLLs and provide a more LabVIEW friendly interface. When I load the Panel into the .NET container and write my code in LabVIEW to display a few rows, I get no errors and everything seems to work fine. No memory leaks, it's all working seamlessly. 

However if I add more rows, eventually LabVIEW gets into what I will refer to as a bad state. Here are the symptoms of a bad state:

1. Pull down inputs do not display any text.
2. NumericUpDowns go blank when in edit mode.
3. Text entered into text fields does not display while entering the text (all white) but does when edit mode is exited. However, the strings are entered backwards. If I were to type "LabVIEW" and click somewhere else or hit enter, I would see "WEIVbaL" in the text box. 
4. Entering more text into a text box concatenates it (at the front of the string, still backwards) instead of replacing, as is default behavior.

I would understand that my code is doing something wrong if this were the extent of the error. However the problems are not limited to controls in the .NET container. In LabVIEW, some inputs (.NET I'm assuming) don't work. For example I can't enter text into a "Save VI" filename input if I try to save a new VI.

The problem goes away when LabVIEW is restarted, and then my code works fine for a few runs until some unknown situation occurs and the bad state repeats. Luckily LabVIEW 2009 (which I'm using) and Vista (which I'm using) seem to work happily together to relaunch quickly.

I understand that from my description, it would take someone who has solved the exact same situation to understand what's going wrong and what I can do (which I am not expecting). I am however, wondering two things. One, how does one debug a .NET container? Yes I trace errors in LabVIEW and no none are thrown even though my C# code is written with extensive error checking/handling. And two, how did I manage to get LabVIEW in such a bad state? Are there certain windows calls I shouldn't/can't be making? Has anyone seen any similar problems?

Thanks,

Mac 

[smercurio_fc]

I don't have that grid, so there's no way for me to test this. I can say that trying to use complex .NET controls in the .NET container is typically an exercise in futility. .NET controls typically work under the assumption that they are housed in a System.Windows.Forms object, and LabVIEW ain't one of those. With grids the basic issue is that a System.Windows.Forms object provides a binding context, and LabVIEW front panel does not, though you can create one. Sometimes setting the VI to run in the "user interface thread" helps.

One thing I don't understand is your reference to using a wrapper DLL in order to call the Xceed DLLs. I thought you're dealing with a .NET control? Why would you need to create a wrapper DLL?

[Gaulinmp]

Hi Saverio,

Thanks for the quick reply! Unfortunately neither using a GroupBox as my container (instead of Panel) nor including a Binding Context works, the problem persists. The reason I have written a wrapper DLL is threefold:

Firstly it greatly reduces the number of .NET calls LabVIEW must make when I can pass in my data as an array or XML object and have .NET do the parsing/formatting/table creation internally.

Secondly, I am overriding the default Xceed Grid objects to provide custom functionality, which I'm not sure I could do in LabVIEW.

Thirdly, the Xceed Grid uses events to add data. For example when a row is created, an event is fired with a pointer to the sub-grid which is attached to the row. This pointer is not available otherwise, so I have to write a method that grabs and saves that pointer in the overridden row class.

Thus the easiest and fastest method I perceived was to write a wrapper DLL that hid the obfuscated Xceed calls required and presented LabVIEW with a simple interface. And perhaps I am creating more problems than I am solving.

As an additional question, do you know how LabVIEW handles creating the .NET container object? Does it call the constructor when the VI runs? I assume it must call the constructor when the control is first added to the container in edit mode because any content that can be is shown. 

Also in case it ever helps anyone, when displaying pull downs in a .NET container, the pull down gets cut off at the edge if you don't use the method: panel.SetTopLevel(false);. That took me a while to figure out.

Thanks,

Mac