CVI (?) DDE support in a Visual Studio project

[Pawel Tokarczuk]

I have a large, existing s/w project (dialog-based, MFC, Visual Studio.NET 2003 Pro). I want to add some simple DDE support, which LabWindows/CVI seems to offer. I don't need any extra UI elements. Can I simply include the CVI DDE libraries (and headers ?) in a Visual C++ project ? If so, what is the minimum package that I should buy ? The task in hand does not require any NI h/w; the DDE s/w is all I need.

[bilalD]

Visual Studio already includes DDE functions you can use for this purpose. Here are some examples provided by microsoft as well. This is probably the simplest route to take without adding any additional dependencies.

Hope this helps

Bilal Durrani
NI

[Pawel Tokarczuk]

Bilal,

Thanks for the pointers to those samples.

Of course, I know about DDE/DDEML; what I don't know is how to use them. This subject is notorious for being poorly documented. I've come across a variety of code samples - in straight DDE, using DDEML, and encapsulating DDE in C++ classes (as in your example).
Without exception, these have all been obese and unreadable; also, irrelevant to what I want to do, since they invariably assume a clipboard format of CF_TEXT, which is used in toy examples and can't be changed.

I've also come across a few shareware ActiveX controls which were meant to provide some DDE functionality. However, some of these produce code that won't compile under MSVC++, some are incomplete in what they do, and some won't e
ven install and register properly.

I was asking about NI's way of doing this, since CVI provides a small collection of DDE functions, all of which I can understand. The point of my query was to find out whether I could use these (originally "C") functions in a C++ project, since, in order to do anything useful, my all-important client callback function has to do things in C++ (such as passing data back up to my dialog class for further processing).

All in all, the cost of buying CVI would probably be worthwhile, given the time it would save me. I just need to know whether I can incorporate the CVI DDE functions in a C++ project, or whether - perhaps - I should use something designed specifically for VC++, such as the Data Socket classes in Measurement Studio.

That's just by way of background. Thanks for writing in.

Yours

Pawel Tokarczuk

[bilalD]

Yes you can use the CVI dde functions from MSVC. Make sure you link against the cvirt.lib found under ..\CVI\extlib to avoid any linker errors. You will also need to add the ddesupp.h file to the C++ project as well.
I just tested this with MSVC and it works great.

Hope this helps

Bilal

[Applications Engineer]

Hi,


As suggested by Bilal, it would be fine to use CVI DDE functions from MSVC.

Best Regards

Atul Wahi
Applications Engineer
www.ni.com

[Pawel Tokarczuk]

Gentlemen,

That approach sounds good to me.
I shall try it with a sample project to see whether
any C/C++ issues arise.

Let's call that a closed thread for now.

Yours

Pawel Tokarczuk

[Pawel Tokarczuk]

Gentlemen,

Some follow-up to your earlier postings that may be useful to other readers:

1. The suggested approach works fine - I've written a trivial VC++ project to talk to the cells of an Excel worksheet. I mean, in C++, without using the CVI IDE or any other features apart from some included files.

2. I've included the following files (from the "msvc" folder of CVI) in my project:

cvidef.h
cvirte.h
ddesupp.h

cvirt.lib

3. The client callback function doesn't have to be in ANSI C - it can also be in C++. This makes all the difference in the world to me. The test for this is to define it within a C++ file and issue some calls to new and delete.

4. The client callback function may ei
ther be a global (not a member of any class), or a static member of (say) the main dialog class of the application.

In the former case, the way to pass data to the rest of the application is to fetch a pointer to the main window using AfxGetMainWnd(), then copy the DDE data to a suitable working array (making this global simplifies matters somewhat), and finally call some member function of the dialog class:
MyTempDlgPtr->ProcessTheDDEData(// some parameters);

In the latter case, declare the function as "static" in the header file, but miss the word out in the implementation. Use the fully qualified function name (CMyCustomDialog::MyCClientCallback) in the call to ConnectToDDEServer(). This latter approach is not necessarily better than the former one, since a static member function can only refer to static member data. Then again, declaring everything "static" isn't a terrible hardship, if your C++ application has only one instance of the main dialog (almost invariably true).


Overall, the "global" declaration is probably easier to code and to use, with fewer restrictions.

Thanks again for your advice.

Over and out, barring mistakes detected by other visitors.

Pawel Tokarczuk

[Pawel Tokarczuk]

Gentlemen,

I've made some progress on my application, and I'm thinking about the right way to redistribute it. At the moment, I expect to:

- Bundle the CVI DLL's in the program directory within my installer.
- Create a self-extracting Zip archive from C:\WINNT\SYSTEM32\cvirte\ and instruct users/customers to unpack it to the default directory. This folder merely contains a couple of fonts and some lists of error messages which my application may need to access from time to time.

I'd like to ask:

- Is this the most correct thing to do ?
Remember, I have built the project by including some CVI LIB files in a MSVC++ project - it's no use suggesting that I "create a distribution kit from the CVI ID
E".
- Is this going to be legal ?

Alternatives, please, if either answer is "No".

Yours

Pawel Tokarczuk