The wrapper files that you sent have been generated with a 64 bit installation of and are therefore targeting the x64 platform. This is visible from looking e.g. at the
GetProperty(0x1, VT_EMPTY, (void*)&result);
void SetImage(__int64 propVal)
SetProperty(0x1, VT_EMPTY, propVal);
The 32 bit version of would have
int instead of
__int64 here. These two automatically generated wrapper function implementation also directly show the problem: Rather than passing the
__int64 value through the
IDispatch interface, the code passes an empty variant (
VT_EMPTY) - which is exactly the reason why your image won’t show (and I would guess that there is a lot going on in the trace output of Visual Studio whenever
GetImage is called.
This is a known and very unfortunate flaw of the wizard that builds the ActiveX control wrappers for MFC applications (and it is in fact not limited to this one; the corresponding Delphi wizards are also struggling with
__int64 properties - the only tools doing well on this so far to my knowledge are aximp and tlbimp that generate the wrapper DLLs for .Net projects).
My recommendation to circumvent this problem:
- When using the MFC class wizard to generate member variables for ActiveX controls on a dialog, remove the trailing “1” from the default settings (i.e. from the class name and from the file names) and let it do its botched job.
- Open the source folder of any of the Visual C++ tutorials that ships with which contains the ActiveX control that you are after. From there copy the …ctrl.h and the …ctrl.cpp file into your own source folder, overwriting the files that the wizard just generated.
- Build your project. If everything worked your source should simply compile. If it doesn’t then redo step 1 and 2 but watch out for (and take into account) any subtle differences in class name and/or file name that your particular Visual Studio version might try to use and the wrapper files shipped with .