LabView interface with DLL that uses ActiveX

[ikaliniouk]

I've written a DLL using Microsoft Visual Studio 2005. This DLL uses ActiveX (MSXML4.0). It works fine being called from other applications created in Microsoft Visual Studio. It crashes being called from LabView 7.1. By commenting out everything, I've figured out that it crashes on the call to ActiveX (no problems if this call is commented out). What should I do to make it work?

I've tried using CoInitialize at the initialization of DLL; it didn't solve the problem.

Additional information: DLL is using MFC in a Static Library, not using ATL, Character set = Not Set.

The functions are defined in C calling convention (not __stdcall).

Please help.

Thank you.

Irina Kaliniouk

[Lycangeek]

LabVIEW itself calls the CoInit methods for its threads, so that shouldn't be necessary. I'm not sure what the problem is, but when I hear things like ActiveX, MFC, etc. I start thinking about the UI thread. I would recommend ensuring that the VI containing the Call Library Node is marked to run in the UI thread, not "same as caller". Often times this makes the problem go away as MFC assumes that it is being called by the same thread as the one pumping messages, and is part of the STA.

[ikaliniouk]

Thank you for your answer, but that is not the case. There is no UI in this DLL, but it is using some convinenient MFC classes, like threads, CString, etc. The threading really was not even involved in the example that crashed. The function that crashed was

selectNodes on MSXML2::IXMLDOMNodePtr. Here is the code:

MSXML2::IXMLDOMNodeListPtr 

selectNodes (LPCTSTR expression, MSXML2::IXMLDOMNodePtr pStartNode)

{

CComBSTR quesryBstr (expression);

return pStartNode->selectNodes (quesryBstr.m_str); //_bstr_t(expression));

}

where the pStartNode was a root node of

MSXML2::IXMLDOMDocument2Ptr m_pXMLDoc;

hr = m_pXMLDoc.CreateInstance ("Msxml2.DOMDocument.4.0", NULL, CLSCTX_INPROC_SERVER);

I commented out really everything except this function, so there was nothing to corrupt the memory or any other problems.  

What can be of a problem?

Thanks.

[Lycangeek]

The only thing I see that could be it was the LPCTSTR. If you compiled the DLL in wchar_t mode, then the LV strings and your strings wouldn't match up. I would recommend launching LabVIEW as a debug process (or attaching) from Visual Studio. You can then set breakpoints in your DLL and see what is going on.

[ikaliniouk]

For some reasons I don't understand when I try to attach the process to the LabView openning my VI it doesn't stop in my break points even in DLL attach / detach.

When I try to attach the process to the application that was built by LabView from my VI, the application crashes without stopping in my breakpoints as well.

If I just try to run this application without trying to debug it, it runs fine and returns all the correct results.

I forgot to mention I use the following sequnce in DLL attach function, but it didn't change anything when I commented everything out.

CWinApp::InitInstance();

CoInitialize(NULL);

// should be done in the main program

AfxEnableControlContainer();

Regarding LPCTSTR I use Charater set Not set, so it is equivalent to char *. Besides, the DLL doesn't crash if I just get some parameters and return some strings back, it crashes only if I use MSXML 4.0 object.

Any other suggestions?

Thanks

[Lycangeek]

I'm afraid I'm running out of things to suggest by this forum. I'd recommend contacting Tech Support so that you can have some dedicated time from our application engineers.

However - I do still strongly recommend that you try setting the execution mode of the VI to UI thread. You'd be amazed how many problems that solves.