replacing deprecated atl attribut - atl

How should I replace deprecated atl code (Visual Studio 2015 warning C4467)?
The data structure is within a file DataType.h
struct SData4
{
SData4() { Init(); }
~SData4() { Delete(); }
void Init();
void Delete();
LPWSTR m_strSomething;
[string] LPWSTR m_strCode;
};
The IDL file contains method declerations using this structure as follows:
// interface version 6.0
[
object,
uuid(...-.-.-.-.),
helpstring("IData4 Interface"),
pointer_default(unique)
]
interface IData4 : IUnknown
{
[helpstring("method SetData")] HRESULT SetData([in] long lLen, [in, size_is(lLen)] SData4* s);
};
What I don't get is, that there are LPWSTR definitions without [string] attribute within the same struct. And it has worked for a decade :/ The microsoft help page https://msdn.microsoft.com/en-gb/library/8tesw2eh.aspx states that
[string] Indicates that the one-dimensional char, wchar_t, byte, or equivalent array or the pointer to such an array must be treated as a string.
So I have to find a way to tell DCOM that this WCHAR * is a string. But why and how?
Ok, I found an indication within the book "Inside Distributed COM" from Guy and Henry Eddon. They state, that the [string] attribute allows the user to send strings without defining the actual string length. If the attribute is omitted, you have to implement memory management of this string using CoTaskMemAlloc and CoTaskMemFree.

To replace [string] or another ATL attribute, the generic solution is to enable Expand Attributed Source option in project settings. Then, when building the code you will have a non-attributed C++ code where attribute processor expanded the attributes. Inspecting the expanded code you see what non-attributed code corresponds to what you had in first place.

Related

MIDL changes the Interface name

I have a COM dll , which is consumed by .NET applications using COM Inter-op.
In one of the CoClasses , there is an Interface called IT6TrackData and it has one get property called TrackData
From the IDL file:
Interface IT6TrackData
{
[propget, id(1)] HRESULT TrackData([out, retval] SAFEARRAY(BYTE) *pVal);
}
When the TLB file is viewed for the above IDL file, it shows the property as trackData ( t in lower case)
For some reason the Client application were referring to this property as trackData and everything was working fine until now.
As part of enhancement the above Interface was upgraded to have a put property
Interface IT6TrackData
{
[propget, id(1)] HRESULT TrackData([out, retval] SAFEARRAY(BYTE) *pVal);
[propput, id(1)] HRESULT TrackData([in]SAFEARRAY(BYTE) pVal);
}
Now when the TLB file is viewed for the above IDL File, it show the property as TrackData ( t is in upper case), this is breaking the old .NET clients who continue to refer to the
trackData with the “t” in lower case.
I have gone through this KB article
http://support2.microsoft.com/kb/220137/en-gb
but is there a way out, does anyone know of a fix for this issue.
your attention is appreciated.
The IDL File
import "oaidl.idl";
import "ocidl.idl";
[
object,
uuid(72867CE8-41B6-459E-A258-C7A162A26D5E),
dual,
nonextensible,
helpstring("ITFST6TrackData Interface"),
pointer_default(unique)
]
interface ITFST6TrackData : IDispatch{
[propget, id(1), helpstring("property TrackData")] HRESULT TrackData([out, retval] SAFEARRAY(BYTE) *pVal);
[propput, id(1), helpstring("property TrackData")] HRESULT TrackData([in]SAFEARRAY(BYTE) pVal);
};
[
uuid(1D7ABC17-2738-4373-9B6B-239E344DBD21),
version(1.0),
helpstring("SampleCom 1.0 Type Library")
]
library SampleComLib
{
importlib("stdole2.tlb");
[
uuid(2013CC98-47A7-468F-912A-2A2CAE25E327),
helpstring("TFST6TrackData Class")
]
coclass TFST6TrackData
{
[default] interface ITFST6TrackData;
};
};
This is the side-effect of a hack in the type library generator built into Windows. It has a workaround for trouble caused by a case-insensitive language. Which might declare a type in one casing but refer to it elsewhere in another casing. Visual Basic is the prime example of such a language.
The hack is very crude, it takes the casing of the first identifier it encounters and then changes the casing of any subsequent identifier to match. The most typical cause of an unexpected casing change is the name of a parameter, typically spelled with a lower-case first letter. So you probably had a "trackData" method parameter in a previous version of the code.
And in your revision, either the order of the identifiers changed or you renamed or removed that parameter. Now getting "TrackData" instead.
If you have existing client code around that depends on the original casing then there's little you can do but change the casing in your source. Fugly fix, but unsurprising to your clients since they can't tell the difference :)

"Invalid use of New Keyword" in VBA using old com object written in c++

I've scoured the web and stackoverflow for this answer but can't find anything. I have written a com object in C++ (for the fist time) that works when used in vbscript and through cocreateinstance in an executable file. So I decided to see if it would work in Excel VBA.
So I went into "References" and located my object there. Checked the box and started coding away. The following is the VBA code.
Function doCos(x As Double) As Double
Dim t As SimpleLib.IMath
Set t = New SimpleLib.IMath ' <- "Invalid use of New keyword" error here
doCos = t.Cos(x)
End Function
Intellisense recognizes my object in the Dim statement, but it does not appear when I use a Set statement. Obviously I am using a registered type library or else intellisense wouldn't work at all. Again, the com object can be used in vbscript or an executable, but for some reason can't be used, at least with the new keyword, in VBA.
Does anyone have an idea what may be wrong, or what may have to be added to the com object? Thanks.
One approach is to define a coclass in the IDL that includes the interface needed (IMath in my case). NOTE: That the [default] interface is hidden by default. So I simply defined interface IUnknown as the default. After compiling with MIDL a type library is generated which one should register with regtlibv12.exe.
I then included an additional IF statement in DllGetClassObject like if (rclsid == CLSID_Math) where CLSID_Math is corresponds to the CLSID defined in the file automatically generated from MIDL. All I did was copy and paste the body of the IF statement from if ( rclsid == IID_IMath ), updated the DLLRegisterServer and DLLUnRegisterServer functions, recompiled the project, and regsvr32.exe.
So the following works now.
Function docos(x As Double) As Double
Dim a As SimpleLib.IMath
Set a = New SimpleLib.Math
docos = a.Cos(x)
End Function
Thanks to Hans for the tip about the coclass. Learned something new and useful.

Why do my C# and C++ dlls exhibit different behavior?

I am working on a project that involves the creation of a dll that honours a certain interface in order to plug into some software in order to add functionality to it. This is done by a dll that calls my dll (I do not have the source code for the dll that does the calling). Originally I was given an interface and a C# implementation that created a COM visible dll. However after using this for a while I found I wanted to make use of some large C++ libraries and as creating wrappers would take a long time I thought about creating a C++ ATL COM dll instead. I did this and the methods of my class appear to be called correctly (I register my dll, run the program and the methods appear to be called in the correct order), however I have found some of the behavior to be different.
I am not sure how to go about explaining this as my code relates to a closed source API but perhaps if I describe an example someone might have some ideas as to where I might want look.
For instance, in the C# dll I attempt to open a file by doing this:
FMANFileControl fileControl = new FMANFileControl();
FMANFile wFile = null;
const string filePath = #"C:\Data\April 4\Data_IDA.wiff";
wFile = fileControl.GetFileObject(filePath, 1);
long numSamples = wFile.GetNumberOfSamples();
I get the correct number of samples.
In my C++ dll I have this (with some of the HRESULT checks removed in order to keep the code shorter):
std::string filePath = "C:\\Data\\April 4\\Data_IDA.wiff";
_bstr_t fileName(filePath.c_str());
IFMANFilePtr ipFMANFile;
IFMANFileControlPtr ipFMANFileControl;
hr = ipFMANFileControl.CreateInstance(__uuidof(FMANFileControl));
hr = ipFMANFile.CreateInstance(__uuidof(FMANFile));
ipFMANFile = ipFMANFileControl->GetFileObject(fileName, 1);
long numSamples = ipFMANFile->GetNumberOfSamples();
but the files does not open correctly, resulting is zero samples.
Using oleview I looked at the typelib and it says this for the function:
[id(0x00000001), helpstring("method GetWiffFileObject")]
IFMANWiffFile* GetWiffFileObject( [in] BSTR WiffFileName, [in] long sample);
The file I get information from is one that is being written to during an experiment and just before it obtains more data it calls my method and I should be able to obtain the newest file. In the C# dll this is possible, but in the C++ dll this is not. While I realize the specifics of this is hidden, I am wondering is anyone has any idea why a C++ COM dll and a C#, comvisible dll that make use of the same interface would exhibit different behavour when being called by the same dll.
I am pretty stumped at this moment so any ideas at all would be appreciated, even if they turn out to be way off base. I can share my source code if anyone thinks they might be able to help.
EDIT:
I tried the solution to answer 1, however I could not compile my code. When reading about this I found this post:
Differences between [in, out] and [out, retval] in COM IDL definitions
that seems to suggest that since the FMANFile pointer is marked [out, retval] that the method becomes:
IFMANFilePtr ExploreData::IFMANFileControl(BSTR filename, long sample);
or am I misinterpreting that article?
EDIT 2:
Got it working though I am not really sure why.
Originally I had the variables declared in the header as private member variables of the class, like this:
class ATL_NO_VTABLE CUserIDA :
public CComObjectRootEx<CComSingleThreadModel>,
public CComCoClass<CUserIDA, &CLSID_UserIDAObject>,
public IUserIDA
{
.
.
.
public:
STDMETHOD(GetSwitchCriteria)(DOUBLE* intensity, DOUBLE* minMass, DOUBLE* maxMass, VARIANT_BOOL *selectIntensity, LONG* numOfDepCycles);
.
.
.
private:
ExploreDataObjects::IFMANWiffFilePtr ipFMANWiffFile;
ExploreDataObjects::IFMANWiffFile2Ptr ipFMANWiffFile2;
};
Just to try it I moved them to the top of the class delcaration like this:
class ATL_NO_VTABLE CUserIDA :
public CComObjectRootEx<CComSingleThreadModel>,
public CComCoClass<CUserIDA, &CLSID_UserIDAObject>,
public IUserIDA
{
ExploreDataObjects::IFMANWiffFilePtr ipFMANWiffFile;
ExploreDataObjects::IFMANWiffFile2Ptr ipFMANWiffFile2;
I thought that by default these would also be private members and the same as before so I am at a loss to explain why this seemed to work. Can someone explain this?
Your C++ code is correct, except for the following line:
hr = ipFMANFile.CreateInstance(__uuidof(FMANFile));
It doesn't make any sens, because ipFMANFile is initialized once again in the next statement.
Unfortunately, this IDL declaration:
IFMANWiffFile* GetWiffFileObject([in] BSTR WiffFileName, [in] long sample);
is limited for debugging purposes since it doesn't support the native COM mechanisme for the exception reporting via HRESULT. The COM compliant declaration would be:
HRESULT GetWiffFileObject([in] BSTR WiffFileName, [in] long sample, [out, retval] IFMANWiffFile** fileInstance);
I believe that you are unable to change the library's code so I suggest you to try some external debugging tools like 'procmon.exe' and 'dbgview.exe' to inspect the application events when you run the CPP test case. Look for all failed actions.
I hope this will help you somehow

Writing a simple ActiveX control for IE that has one method

I'm learning how to write a scriptable ActiveX control. My goal is to have a tiny control that can check to see if something is installed on the system. What I've done so far is:
Create a MFC ActiveX control project in VS2008
Add some 'safe for scripting' bits that I found here.
Extend the IDL to provide my "IsInstalled" method, which for now returns TRUE unconditionally (but will later read some keys from the registry.)
Build the control and run regsvr32 on it. I verified that it does show up in HKEY_CLASSES_ROOT, and when I instantiate the object, the IE Developer Tools "Locals" pane shows that the object is of type _D[my plugin name]. Not only that, but my IsInstalled() method shows up underneath that object.
However, when I call IsInstalled(), I just can't get it to work:
JScript Debugger - Breaking on JScript runtime error -(n http://img138.imageshack.us/img138/1586/whycomwhy.png
I'm at a loss. I've also tried making IsInstalled a property instead of a method, using VARIANT_BOOL instead of boolean instead of BOOL in the IDL, you name it.
Here's the relevant excerpts of code.
The header:
afx_msg VARIANT_BOOL IsInstalled();
The implementation:
afx_msg VARIANT_BOOL
CMyAXCtrl::IsInstalled()
{
return TRUE;
}
The dispatch map:
BEGIN_DISPATCH_MAP(CMyAXCtrl, COleControl)
DISP_FUNCTION_ID(CMyAXCtrl, "IsInstalled", dispidIsInstalled, IsInstalled, VT_BOOL, VTS_NONE)
END_DISPATCH_MAP()
The dispatch part of the IDL:
[ uuid(6B662202-CF13-4144-AA33-C3FEE9C2C962),
helpstring("Dispatch interface for My Control")]
dispinterface _Daxplugin
{
properties:
methods:
[id(1)] VARIANT_BOOL IsInstalled();
};
If there's any other relevant bits of code I should provide, let me know. But I'm stumped here. Thank you in advance!
You almost certainly have the wrong prototype for a scriptable function. OLE Automation for scripting languages tends to rely on returning a HRESULT then using an out parameter for the actual return code.
So change it to
[id(1)] HRESULT IsInstalled(VARIANT_BOOL* p);
Also TRUE != VARIANT_TRUE, you must return VARIANT_TRUE which is equal to -1 instead of 1.
Hope some of that actually helps, but without the actual error I might be mistaken :)
You could mark your control as save for scripting by implementing IObjectSafety or by marking the Object as save while registering it (as supposed by the link you provided).
Have you run regsvr32 after adding the code to mark it save for scripting?
You can check the registry if your control has the safe for scripting bits set.
If the bits are set you will find the two keys {7DD95802-9882-11CF-9FA9-00AA006C42C4} (Safe for Initialization)
{7DD95801-9882-11CF-9FA9-00AA006C42C4}(Safe For Scripting) as subkeys of ImplementedCategories in your object.
I would suggest to implement IObjectSafety since it doesn't depend on your class to register itself.

Convert VARIANT to...?

Note:
Attempting to invoke a method of an interface, of which the return type is _variant_t
Code:
_variant_t resultsDataString;
_bstr_t simObjectNames;
simObjectNames = SysAllocString (L"TEST example 3");
resultsDataString = pis8->GetSimObject (simObjectNames);
inline function illustrated below, contained in .tli FILE:
inline _variant_t IS8Simulation::GetSimObject ( _bstr_t Name ) {
VARIANT _result;
VariantInit(&_result);
HRESULT _hr = get_SimObject(Name, &_result);
if (FAILED(_hr)) _com_issue_errorex(_hr, this, __uuidof(this));
return _variant_t(_result, false);
}
Note:
resultsDataString is of struct tagVARIANT:
VARTYPE vt is 9 (unsigned short)
IDispatch IDispatch interface pointer
Question
How can I then convert or extract the value?
Possible using VariantChangeType?
Another way?
Edit:
Note:
Looking to transform the following, Visual Basic code to Visual C++
MFC or ATL, if need be
Ideally, pure C++
Visual basic equivalent:
Public example1, example2 As SIMUL8.S8SimObject
Dim numberOfexamples As Variant
Dim resultString As Variant
Set example1 = MySimul8.SimObject("Example 1")
Set example2 = MySimul8.SimObject("Example 2")
numberOfexamples = example1.CountContents + example2.CountContents
resultString = CStr(numberOfexamples) & "*"
It appears you are using C++ as a COM client by relying on the VC++ compiler's built-in COM support. To make coding the client "easier" you've used #import to generate C++ wrapper classes that attempt to hide all the COM details from you - or at least make the COM details simpler. So you're not using the COM SDK directly, but are using a client-side framework (I think of it like a light-weight COM-only framework akin to ATL or MFC).
Your example code, however, seems to be mixing the direct low-level COM SDK (VARIANTs, BSTR, SysAllocString) with the #import COM framework (_variant_t, _bstr_t, XXXXPtr). COM from C++ is complicated at first - so in a perfect world I would suggest getting to know the basics of COM before going too far forward.
However, if you just want something to work I would guess this is #import-style-of-COM-clients version of the VB code you provided:
_variant_t example1Var;
_variant_t example1Var;
SIMUL8::S8SimObjectQIPtr example1; // I'm guessing at this type-name from the VB code
SIMUL8::S8SimObjectQIPtr example2;
example1Var = pis8->GetSimObject(_bstr_t(L"Example 1"));
example2Var = pis8->GetSimObject(_bstr_t(L"Example 2"));
if (example1Var.vt == VT_DISPATCH && example2Var.vt == VT_DISPATCH)
{
// **UPDATE** to try to spoon feed the QI ptr...
example1 = IDispatchPtr((IDispatch*)example1Var);
example2 = IDispatchPtr((IDispatch*)example2Var);
// Does this screw-up reference counting?
int numberOfexamples = example1->CountContents + example2->CountContents;
}
UPDATE:
Documentation on #import This makes using COM from C++ much easier, but is yet one other thing to learn...
Take a look at the MSDN docs for _variant_t
There is a ChangeType method as well as Extractors.
Edit: Once you have an IDispatch pointer, you need to use QueryInterface to get a specific object type with members and methods, or use IDispatch::Invoke. You can look at the MSDN Docs for IDispatch. Either way, you need to know about the object type that is being returned by the IS8Simulation::GetSimObject call.
Edit #2: Based on your VB code update, you want to use the same kind of code for C++, i.e. use the S8SimObject type in its C++ form (look in the generated .tlh file for _COM_SMARTPTR_TYPEDEF). Then you can directly do the same thing with CountContents. Otherwise, you would need to look up the CountContents DISPID with IDispatch::GetIDsOfNames and then call invoke.
You don't have to convert the _variant_t. It contains an IDispatch interface pointer, so you can get it out like this:
if (v.vt == VT_DISPATCH)
{
IDispatchPtr pDispatch = v.pdispVal;
// Do something with pDispatch.
// e.g. assign it to a strongly-typed interface pointer.
}
There is a concept of "value" for an object (DISPID_VALUE).
Here is a codeproject.com article on resolving VARIANTs that might help.