The most significant information is done by your first attempt:
error C2259: cannot instantiate abstract class due to following members: unsigned long __stdcall IUnknown::AddRef(void)
As the compiler said, you cannot instantiate this class in any way, because it misses something; if you write the code of that class the solution is obvious: implement unsigned long __stdcall IDgnWords::AddRef(void) and this will fix you problem
by writing IDgnWords* words; you have allocated only a pointer to that class, but you should initialize it with new IDgnWords() before use it. If you don't do it, the pointer hold a random address and trying to use it generates a memory protection faultCComPtr<IDgnWords> words; declares a smart-pointer to the IDgnWords class, then all that I said about IDgnWords* words; is still valid, and this is the reason of your crash. CComPtr simply wraps a IDgnWords* and calls the Release() method for you when the variable goes out of scope
Now one thing that isn't making sense is I used a different class from this SDK and I was able to call CoCreateInstance( CLSID_DgnVocTools, NULL, CLSCTX_ALL, IID_IDgnVocTools, (LPVOID*)&pIDgnVocTools ) ;
I would think that I would need to create and instance of the IDgnWords object, but there's no CLSID for it. If I don't create and instance of that VocTools object I used in the previous paragraph, it craps out on me just like the IDgnWords object is doing now.
You think this could be the problem? It seems odd to me that creating a "new" object doesn't seem to work for this.
I thought that IDgnWords was a class that you wrote because COM classes should be created trough their class factory using the CoCreateInstance() function, or queried to another class that you have already instantiated using the QueryInterface() method.
If there isn't a CLSID_ trough that you can instantiate the IDgnWords, probably you should first instantiate another class and then query it for the one you need...
I tried searching the internet for documentation about IDgnWords, but I didn't find anything. Dragon Naturally Speaking is a payed product: have you got any documentation from Nuance? Have they give you any technical contact to ask for?
i have an excel add in application. when i try to install the application on target machine.the add in failed to add.
when i check the add in in excel my add in there but shows in inactive add in application. when i try to add the com in .. its shows me a runtime error occured during the loadin of com add in ... how can i resolve it.
I need to call a function written in C# from the unmanaged code.
The code from where I have to call the function is purely written in VC++ and it come in the unmaged part of the solution code.
Most of the solution is written in C# .NET 3.5.
Please help me out.
I have to implement a COM class with VB.NET. An object of this class has then to be created from a VB6 DLL. The code for the COM dll is very simple:
PublicConst ClassId AsString = "58faad86-bbac-4b20-9ab5-fe32bdac0a68"PublicConst InterfaceId AsString = "f8dbb078-5f1e-4304-a390-3e8e88983f98"PublicConst EventsId AsString = "113d2163-f8db-4d99-88e5-58d13b8d2cf4"#End Region
EndSubPublicWriteOnlyProperty CurrentSPFProjectStatus() As SchemaCompInterfaces.SPFProjectStatus Implements SchemaCompInterfaces.IEFAdapter.CurrentSPFProjectStatus
Set(ByVal value As SchemaCompInterfaces.SPFProjectStatus)
EndSetEndPropertyPublicFunction DocumentExistsInTool(ByRef oDocumentIObj As SchemaCompInterfaces.IObject) AsBooleanImplements SchemaCompInterfaces.IEFAdapter.DocumentExistsInTool
Following many more functions from the IEFAdapter interface...
The dll and tlb are created and registered.
The test code for the VB6 client to use this COM class is also very simple:
Dim adapter As SchemaCompInterfaces.IEFAdapter
Set adapter = Interaction.CreateObject("MyEFAdapter.AdapterWrapper")
Now when I'm running this code, I'm getting the Run-time error '13' Type mismatch in the CreateObject line. Late binding with
Dim adapter asObject
seems to work for my test code, but is not a solution for me, because I can't change the proprietary VB6 code where the COM object is created. So somehow the interface "SchemaCompInterfaces.IEFAdapter" is not known...
Any ideas how to get close to this problem?
In the project properties I checked the flag for registration with COM-Interop. Perhaps something to do with the ClassInterface?
I'm relatively new to VB, so don't answer too complex...
want to develop 64 bit application for 64 bit windows OS. I tried all VS2005 settings required to compile code in 64 bit. but when I install application , it get installed into C:\programme Files(x86) folder instead of C:\programme Files . Is it necessary to build code on 64 Bit OS.
You can build 64-bit applications on a 32-bit OS using Visual Studio 2005.
Visual Studio uses a 64-bit cross compiler to built 64-bit applications because Visual Studio is itself a 32-bit application.
When installing Visual Studio, this 64-bit cross compiler is not installed by default.
You have to customize the installation and manually select the x64 compiler for installation.
If you're not sure if you've installed the x64 compiler, run the Visual Studio installation again and do a modification to select this compiler.
After the compiler is installed, you can use it by selecting a new x64 configuration from Build -> Configuration Manager -> Active solution platform.
Please note that the target path is different for Win32 and x64 builds.
I love work. It gives me something to do between weekends.
I used DllRegisterServer() overrided function for registering 64 bit COM DLL. I register DLL at Software\Microsoft\Internet Explorer\Toolbar key. It works fine for 32 bit IE, but not work for 64 bit IE. So is there any other key for registering BHO for 64 bit IE.
20> Microsoft (R) 32b/64b MIDL Compiler Version 7.00.0555
20> Copyright (c) Microsoft Corporation. All rights reserved.
20> Processing .\_my_idl.idl
20> Processing C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wincrypt.idl
20>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wincrypt.idl(47): error MIDL2025: syntax error : expecting a type specification or a storage specifer or a type qualifier near "WCHAR"
20>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wincrypt.idl(47): error MIDL2026: cannot recover from earlier syntax errors; aborting compilation
20>LINK : fatal error LNK1240: failed to compile IDL content
So I have 2 questions :
1 - Who/what decides what imports are to be added in the IDL file ? why should it have wincrypt.idl ?
I manually removed the wincrypt import from the the IDL file and compiled it without problem, but that's not a solution since the IDL is auto-generated.
2 - If it gives error on the WCHAR, I assume it's thinking the IDL is in wide-char mode, even is our application is not ?