Derive Classes From the NI wrappers

[souldog00]

Using measurement studio 6.0

I would like to know if I am going to run into any problems deriving classes from the NI wrapper classes?
I particular I will have all the NI stuff in an extension DLL and then either wrap a pointer to a NI control wrapper or derive a class directly from a NI wrapper.

eg
either:
namespace NI
{
class CNiKnob
}
class NI_KNOB
{
private:
NI::CNiKnob* TheKnob_;
}

or

#include "NiKnob.h"

class NI_KNOB : public CNiKnob
{
}

I am doing this to isolate the NI stuff from the rest of my projects.

I know the first method works. I would like to know if there is any funny business with the second. My impression is no.


}

[souldog00]

Ok I know I can derive.

[drohacek]

I'm just curious about your motivation for doing this. Could you elaborate a little bit?

[souldog00]

1. I cannot and am unwilling to migrate to .NET right now.

2. I would like to isolate any dependency on a third party library into a single module.

3. I would like the code in other modules to be syntactically independent of any third party library.
A recompile (change base class or contained class) is ok. Having to rewrite code is not.

4. Measurement Studio 6.0 does not support unicode. I dont know the status of the ,NET version. Isolating the NI stuff in a module means I can compile the other modules with unicode and then perform appropriate conversions accross module boundaries. Actually now that I write this I have doubts about this one and I have not worked out the details

5. I need to add my own serialization mechani
sms (definitely not MFC garbage) to the controls. I need to be able to load the "state" of the control and pass it through a socket, without haveing to create the activeX control or the container window.

6. I would like to encapsulate some extensions to the controls which involve windows messages.

[drohacek]

Very interesting; thank you for responding. Regarding item #4, .NET inherently supports unicode. With respect to what you want to do, I suspect that you cannot use an MFC extension DLL linked to the MBCS version of MFC in an application linked to the unicode version of MFC. But, I haven't tried it and I didn't find anything in a quick search.

If this does turn out to be a problem, another option to try would be to not use the C++ classes to interface to the ActiveX controls and instead use the MFC ActiveX wrapper classes the Visual C++ environment generates. The disadvantages of this approach are 1) you have to manually convert between standard C++ data types and ActiveX data types; and 2) if you want to access the controls from mul
tiple threads, you will have to handle the COM marshaling yourself. I did a quick verification of this approach (with Visual C++ 2003) and was able to get it to work.

Regarding item #5, the controls have a built-in serialization mechanism that might serve your needs. Check out the ImportStyle and ExportStyle methods.

I would be interested to hear what you find out about using MBCS and unicode modules together.