|
Hi,
I am having an issue compiling the ATL/Com dll;
I have Three classes and their interfaces in a com dll as:
1- IMailInterface
2- IMyInterface1
3- IMyInterface2
Now,MFC application uses these interfaces. My application will never directly deal with 2nd and 3rd interface. Everything will be done with the help of IMainInterface. I want to add a method to IMainInterace as
GetMyInterface1(IMyInterface1** ptr); which will retrun the IMyInterface1 pointer
But while comiling getting an error error as:
D:\Work_ganesh\MPlusSrvOpticalDevice\Work In Progress\Ganesh\Samples\DemoCOM\DemoCOM.idl(18):error MIDL2025 : syntax error : expecting a type specification near "IMyInterface1"
D:\Work_ganesh\MPlusSrvOpticalDevice\Work In Progress\Ganesh\Samples\DemoCOM\DemoCOM.idl(18) : error MIDL2026 : cannot recover from earlier syntax errors; aborting compilation
Error executing midl.exe.
I tried adding header file but it didn’t worked.
Thanks.
"A winner is not one who never fails...but the one who never quits"
|
|
|
|
|
Ganesh_T wrote: But while comiling getting an error error as:
D:\Work_ganesh\MPlusSrvOpticalDevice\Work In Progress\Ganesh\Samples\DemoCOM\DemoCOM.idl(18):error MIDL2025 : syntax error : expecting a type specification near "IMyInterface1"
D:\Work_ganesh\MPlusSrvOpticalDevice\Work In Progress\Ganesh\Samples\DemoCOM\DemoCOM.idl(18) : error MIDL2026 : cannot recover from earlier syntax errors; aborting compilation
Error executing midl.exe.
Could you post the actual idl code? That would tell me much more about what went wrong.
Nathan
|
|
|
|
|
Hi,
Can any one give me the details about CoCreateInstanceAsAdmin API.
Thanks & Regards
...swamy 
|
|
|
|
|
I thought this[^] explained it pretty well.
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
hi All,
My VB Client using ATL COM works fine while running under Debug mode but in the release mode it gets crashed as ATL COM tries to fire event to the VB Client
Here are the Details of what i have developed as ATL COM in C+
I have developed a simple ATL COM in C++ , This ATL Com has a dependency which is a DLL , this DLL sends a notification to the ATL COM by using a registering a function of a ATL as callback , i have used a static function of ATL Object as callback function as we cannot give member function of the class as callback function due to "this" pointer.
Now Dll sends notification to this static function of ATL COM and this ATL COM send the notification further to the COM Client by firing event.
Important to note , since notification is received by static function of ATL class , so i had to use global pointer to the ATL COM in that static function to Fire_Event , as soon as global pointer fires events VB client in release mode gets crashed
Here is the code snippet
CTest_ATL *g_pTestATL; // Glboal Pointer
STDMETHODIMP CTest_ATL::funSubscribe(void)
{
g_pTestATL = this;
m_hDLL = LoadLibrary(TEXT("\\DLL_PlaceCall.dll"));
if(NULL == m_hDLL)
{
return S_FALSE;
}
return S_OK;
}
// This is a callback "static" function which gets registered to the DLL
// As this static callback function gets called i am firing event using
// global pointer to ATL_COM as shown below
int CTest_ATL::EventCallBack()
{
g_CallMonitor->Fire_IncomingCall(CComBSTR("This is a COM Message"));
return S_OK;
}
Any pointers in this issue will be a great help.....
with regards
Abhiraj
|
|
|
|
|
garammasala wrote: My VB Client using ATL COM works fine while running under Debug mode but in the release mode it gets crashed as ATL COM tries to fire event to the VB Client
Do you have any code you depend on inside an ATLASSERT statement? These are removed in release builds. Another possibility is that the optomizer is breaking something. You may want to create a release build with debug information so that you can step through the code the compiler is actually generating for the release build.
Also, unrelated to your problem, it looks to me like g_pTestATL and g_CallMonitor could be static member variables of CTest_ATL.
Nathan
|
|
|
|
|
Hi Nathan
< Also, unrelated to your problem, it looks to me like g_pTestATL and g_CallMonitor could be static member variables of CTest_ATL >
I made a mistake while giving the question i.e "g_CallMonitor" is nothing it is the global pointer "g_pTestATL" which is firing the event from the static function.... replace g_CallMonitor with g_pTestATL
I have found the solution to the problem but was not really able to understand the whole solution , Below is the link
http://vcfaq.mvps.org/com/1.htm
May be you can through some light....
|
|
|
|
|
garammasala wrote: I made a mistake while giving the question i.e "g_CallMonitor" is nothing it is the global pointer "g_pTestATL" which is firing the event from the static function.... replace g_CallMonitor with g_pTestATL
That makes perfect sense.
garammasala wrote: I have found the solution to the problem but was not really able to understand the whole solution , Below is the link
http://vcfaq.mvps.org/com/1.htm[^]
May be you can through some light....
I'm not sure what you don't understand. I assume that you've implemented one of the options and had it work, because otherwise you wouldn't know for sure it was a solution. I've used both the hidden window and the GIT solution, so I may be able to answer any more specific questions you might have about them. In general, using multiple threads well will require lots of studying and lots of practice. There are probably articles on CodeProject that can tell you a lot about it.
Nathan
|
|
|
|
|
yes Nathan
Your are right that i have implemented one of the options and my work was done...
Since ATL COM is very vast so no idea where to start exactly to find the solution for the same ,also the solution given in the link which i gave requires a lot of deep understanding of ATL before the solution provided can be understood, As you have said there are so many articles in the Code project that can tell me a lot better about ATL and basically the solution given in the links...
so will request to point some of those if you can... ?
with regards
Abhiraj
modified on Monday, April 28, 2008 1:38 PM
|
|
|
|
|
Hi,
I’m currently having a problem with getting a WTL project to work. I’m reasonably experienced in C++ native Win32 programming, but I’m very much a novice when it comes to any kind of ActiveX programming.
The situation is this: I trying to write program in Visual Studio 2005 Express using C++ and WTL that is going to interact with another program, eSignal, using an ActiveX API that eSignal provides. I have managed to setup the basics so that I can communicate from my software to eSignal. The problem is that I’m unable to setup an event listener using WTL that manages the events coming from eSignal.
The eSignal developers have provided sample code on how to do this, but it uses MFC. VS2005 Express, which I’m using, has no MFC, so I have to convert their code into WTL, and with my limited experience, I’m unable to do that.
I would greatly appreciate if someone more skilled in WTL and MFC than me, can help me in this matter. I only need to know how to set up an event listener that will process the events coming from eSignal. The rest I should be able to manage. I will provide the MFC sample code below. The part that I’m having problems with is the m_pEvents property of the MainDialog class.
Edit:
Code removed.
I've decided to upgrade to a version of VS that has MFC, so I'll be using MFC instead.
modified on Thursday, April 17, 2008 9:33 PM
|
|
|
|
|
We have a template class as below
template <class T>
class EXP_IMP_CTPERF CTPERFPtr
/*] END Class */
{
public:
// constructors
CTPERFPtr();
CTPERFPtr(const CTPERFPtr<T>& in_CTPERFPtr);
CTPERFPtr(CTPERFObject *in_Object);
CTPERFPtr(const CTPERFPointer& in_Ptr);
// destructor
virtual ~CTPERFPtr();
// assignment operators
const CTPERFPtr<T> &operator=(const CTPERFPtr<T>& in_CTPERFPtr);
const CTPERFPtr<T> &operator=(T *in_Object);
const CTPERFPtr<T> &operator=(const CTPERFPointer &in_Pointer);
// == operator
bool operator==(T *in_Object);
bool operator==(const CTPERFPtr<T>& in_CTPERFPtr);
bool operator==(const CTPERFPointer &in_Pointer);
bool operator!=(T *in_Object);
bool operator!=(const CTPERFPtr<T>& in_CTPERFPtr);
bool operator!=(const CTPERFPointer &in_Pointer);
operator CTPERFPointer&();
operator T*() const;
// returns true if the pointer really points to an object of that class
static bool isClassOf(CTPERFPointer& in_Object);
static bool baseObject(T &in_Pointer);
// to get the object T
T *operator->() const;
T *getPtr() const;
};
Now i have two classes say Base and derived.
class Base {};
class Derived: public Base {};
Now a function gets CTPERFPtr<base /> as one of its input parameter.
void Func(CTPERFPtr<base />& base_in)
{
}
The function call is done like
CTPERFPtr<derived> derive;
Func(derive);
Can somebody explain how this works?
|
|
|
|
|
Explain how what works? The instantiation of derive? The call to Func? The declaration of CTPERFPtr<>?
Please specify more precisely what it is that you are wondering.
--
Time you enjoy wasting is not wasted time - Bertrand Russel
|
|
|
|
|
when create atl project, then set multi-byte character, compile, I got error:
DllInstall:
error C2440: 'initializing' : cannot convert from 'const char [5]' to 'const wchar_t []'
then try to modify:
form
STDAPI DllInstall(BOOL bInstall, LPCWSTR pszCmdLine)
to
STDAPI DllInstall(BOOL bInstall, LPCSTR pszCmdLine)
compile:
error C2733: second C linkage of overloaded function 'DllInstall' not allowed
any ideas? thanks!
modified on Friday, April 11, 2008 12:30 AM
|
|
|
|
|
Robe wrote: when create atl project, then set multi-byte character, compile, I got error:
DllInstall:
error C2440: 'initializing' : cannot convert from 'const char [5]' to 'const wchar_t []'
Another way to solve your problem would be to use the system function MultibyteToWideChar to convert your message to unicode when you call DllInstall. (If you're in charge of calling it, that is.) The other solution I can think of would be to just use a unicode project, depending on how much you would have to change for it.
Nathan
|
|
|
|
|
You can change the static const wchar_t szUserSwitch[] = _T("user");
with static const wchar_t szUserSwitch[] = L"user";
regards
|
|
|
|
|
hello,
My code snippet for conv is as follows:
string temp_file;
temp_file = my_dir;
temp_file += string ("\\file.tmp");
the my_dir is externed from some other file n is char* with a directory path as its value ("C:\\Projects").
i'm gettin an exception n the application closes.
i want to know wat is the mistake i'v been doing.
Thanx in advance
The problems that exist in the world today cannot be solved by the level of thinking that created them.
- Albert Einstein
|
|
|
|
|
|
So, instead of giving you a fish, I'll teach you how to catch lots of fish all by yourself. The course is called Debugging 101:
gReaen wrote: string temp_file;
1. Breakpoint there.
2. Observe the involved variables.
3. Is something smelly? That's the thief. Goto 6.
4. Step. Exception thrown? If so, you should have smelled it in 3.
5. Goto 2.
6. End.
It's likely the assignment (will call string::assign et al under the hood, to which you have the sources and should therefore find the error source) that throws because my_dir is in fact NULL, not "C:\\Projects".
--
Time you enjoy wasting is not wasted time - Bertrand Russel
|
|
|
|
|
I have a static library that uses WTL and hence has a _Module variable. I then create another project ( a IE toolbar) that also uses WTL. Because of this i get this assertion to fail:
ATLASSERT(_pAtlModule == NULL); In the CAtlModule constructor...
It could be a simple solution I'm just not aware of, Any ideas on how to solve this ?
Thanks much.
|
|
|
|
|
Silly mistake. I knew it was going to be the case. What was causing the problem is that i had subclassed the CAppModule in my toolbar. So I had an instance of CAppModule in my Lib, and a CMyAppModule in my toolbar. Since they were of diff types, they both needed to be defined but both inherieted from CATLModule.
Solution: Simply removed CMyAppModule, and made _Module in my toolbar be simply an extern, since it was already defined in the Lib.
Thanks!
|
|
|
|
|
I have tried to write a WTL DLL as a wrapper for some utility code which compiles fine with WTL. Want to call it from an MFC app, and assumed I could pass CString's back and forth through the wrapper because WTL docs say the CString class in WTL is compatible with MFC.
I strike a problem in the linking of the MFC app. Works fine with ints but with CString's DLL builds fine, MFC app compiles fine, but fails to link with message
1>TestCallerDlg.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: int __thiscall QXMyWrapper::Hello(class ATL::CStringT<char,class StrTraitMFC_DLL<char,class ATL::ChTraitsCRT<char> > > )" (__imp_?Hello@QXMyWrapper@@QAEHV?$CStringT@DV?$StrTraitMFC_DLL@DV?$ChTraitsCRT@D@ATL@@@@@ATL@@@Z) referenced in function "public: void __thiscall CTestCallerDlg::OnBnClickedButton1(void)" (?OnBnClickedButton1@CTestCallerDlg@@QAEXXZ)
Any ideas? Can you use CString params in a WTL DLL?
= = =
More details... I am using the same header file for compiling the .DLL and the .exe (application).
Trying to follow the advice in http://www.codeproject.com/KB/DLL/RegDLL.aspx[^]
Here's the .h .....
#ifndef _DLL_TUTORIAL_H_
#define _DLL_TUTORIAL_H_
#ifdef _AFX // MFC apps define this
#define DECLDIR __declspec(dllimport)
#else
#define DECLDIR __declspec(dllexport)
// WTL definitions for the non MFC environment
// #define _ATL_MIN_CRT
// #define _CRT_SECURE_NO_WARNINGS
// #define _CRT_NON_CONFORMING_SWPRINTFS
#include <atlstr.h>
#include <atlbase.h>
#include <atlapp.h>
#define _WTL_NO_CSTRING
#include <atlmisc.h>
#endif
class DECLDIR QXMyWrapper
{
public:
QXMyWrapper();
~QXMyWrapper();
int Hello(CString name);
int HelloInt(int val);
};
#endif
If I build a little test app MFC dialog with a button which calls HelloInt only then everthing links and works fine. As soon as I try to call Hello(CString) it fails to link. Seems like it is looking for a function with decorated name containing ...StrTraitMFC... but I think the DLL gets built with a decorated name containing ...StrTraitATL... for the CString param. Chances are it would happily pass the CString in if only I could convince the linker to give it a try 
PS Notice the commented out #defines like _ATL_MIN_CRT ... I kept fiddling thinking the secret might be one of these but I couldn't get it to work... left these commented lines to point to some thoughts anyhow
DaveB
modified on Saturday, March 29, 2008 8:23 AM
|
|
|
|
|
Basically, it's because CString is a different type in MFC than it is in ATL/WTL. Both are instantiations of CStringT, with different traits template parameters (that's the StrTraitMFC and StrTraitATL that you're seeing). Apart from making the strings different types, all the traits do is tell the string how to construct from a resource reference, as MFC and ATL have different ways of identifying the HINSTANCE to use to acquire resources.
Best thing to do? Pass an LPCSTR or LPCWSTR or a std::string or std::wstring rather than a CString - at least they have consistent definitions...
|
|
|
|
|
OK, that sorted it out, thanks. LPCSTR works fine passing strings in, and if I need to modify a string, can hand an LPSTR across and check its length and alter characters up to the available length (eg strncpy). I checked this out and it all works, that's good!
I suppose it would still be easier to use a CString type that can change length etc (eg a CString& parameter). Following the comments you've made, I took a closer look at CString doco in Visual Studio 2005 and found another type I was unaware of called CAtlString. Should that work? I put it in both places to give it a try and got the old linker errors, this time complaining...
1>TestCallerDlg.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: int __thiscall QXMyWrapper::Hello(class ATL::CStringT<char,class ATL::StrTraitATL<char,class ATL::ChTraitsCRT<char> > > )" (__imp_?Hello@QXMyWrapper@@QAEHV?$CStringT@DV?$StrTraitATL@DV?$ChTraitsCRT@D@ATL@@@ATL@@@ATL@@@Z) referenced in function "public: void __thiscall CTestCallerDlg::OnBnClickedButton1(void)" (?OnBnClickedButton1@CTestCallerDlg@@QAEXXZ)
Is it possible to hand CAtlString's back and forth to WTL?
DaveB
|
|
|
|
|
Is CAtlString in the ATL namespace in the WTL DLL? Seems to me that you still have a type mismatch. Something I've found useful in diagnosing problems like this is Dependency Walker[^]. Open the DLL with it and it'll show you the mangled and unmangled exports of the DLL. That'll show you exactly what the DLL *is* making available.
The other thing you have to bear in mind is 'which memory allocator allocated the string's memory?'. You should be OK with standard C++ allocators and classes (based on new/malloc) *if* EXE and DLL both use a DLL version of the C runtime library.
[Later]
I tried this with an ATL DLL and MFC EXE. I used this as the interface between DLL and EXE and it built OK:
#ifndef D_API
#define D_API __declspec(dllimport)
#endif
typedef CStringT<char, StrTraitATL<char> > CMyString;
void D_API DoIt(CMyString& b);
The important bit is explicitly defining the string type to pass between EXE and DLL (and then *using* it). The other thing I found is that I explicitly had to tell the EXE where to find the LIB for the DLL. Once that was sorted, the EXE built fine 
|
|
|
|
|
Excellent. This works perfectly - have tested it now, here's a summary of the working method for the benefit of other readers.
The typedef is in the interface .h, so all you need to do in the MFC is
#include "../wherever/QXMyWrapper.h"
#pragma comment(lib, "../whereverlibis/QXMyWrapper")
In the MFC, can now do all the usual CString operations and function calls, and can transfer other CStrings easily in and out of the QXString form like this
QXMyWrapper wrapper;
CString cstr("qwertyuiop");
QXString str = cstr;
int k = wrapper.Hello(str);
// str is modified by Hello
The working QXMyWrapper.h looks like this...
//--------------------------------------------------------------------------
/*
File name: QXMyWrapper.h
This file contains all the DLL interfacing object declarations,
Notice: we use the same header file for compiling the .DLL and the .exe (application).
The header file exports the target DLL objects if we are building the DLL,
otherwise it imports the DLL objects into an application which uses the DLL.
Here we assume the DLL is being built in WTL/ATL and the caller is an MFC app, so we use _AFX to differentiate the two
Based on http://www.codeproject.com/KB/DLL/RegDLL.aspx
and http://www.codeproject.com/script/Forums/View.aspx?fid=4486
*/
#ifndef _QXMYWRAPPER_H_
#define _QXMYWRAPPER_H_
#ifdef _AFX // MFC apps define this
#define DECLDIR __declspec(dllimport)
#include <atlstr.h> // allows us to use QXString in MFC
#else
#define DECLDIR __declspec(dllexport)
// WTL definitions for the non MFC environment
#include <atlstr.h>
#include <atlbase.h>
#include <atlapp.h>
#define _WTL_NO_CSTRING
#include <atlmisc.h>
#endif
// Define QXString as a specialized CStringT which will behave like the usual MFC CString but
// is consistently defined and has consistent mem (re)allocation between MFC callers and the DLL
typedef CStringT<char, StrTraitATL<char> > QXString;
class DECLDIR QXMyWrapper
{
public:
QXMyWrapper();
~QXMyWrapper();
int Hello(QXString& name);
};
#endif // _QXMYWRAPPER_H_
//--------------------------------------------------------------------------
Finally, in the WTL .cpp you can put all the other stuff you need to implement the wrapper, and this is where all the other #include's needed for your WTL code go, so the shared .h doesn't drg them in and confuse the MFC code. This lets you wrap a WTL DLL effectively and keep it separate from the MFC. The other nice thing is that the debugging works fine, you can step in and out of the WTL code during an MFC debugging session and watch what is happening. Many thanks for the accurate comments to make this all work...
DaveB
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
