|
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
|
|
|
|
|
Hi,
I have written a ATL COM Service with VS 2005. I'm trying load MFC dll from the service. It compiles okay. However, when I am trying to start the service LoadLibrary Fails.
I have overridden the Start() function and written call to Loadlibrary() there.
When using this dll from a simple MFC application it works fine.
What am I doing wrong?
Thanks,
Abhijit
|
|
|
|
|
abhijitr wrote: When using this dll from a simple MFC application it works fine.
Have you tried calling the DLL from an ATL or straight Win32 application? Have you used GetLastError() to find what error LoadLibrary is signalling? Another thing you could try is adding a 'DebugBreak' call just before the LoadLibrary, to get the service to break into a debugger.
|
|
|
|
|
why WTL ListViewCtrl's LVN_GETDISPINFO notification is not getting fired?
i am a WTL beginner
i have a WTL SDI framewnd application
and a user-defined class, which is inherited from WTL CListViewCtrl
to create a virtual listview control, will act as view class of the application
i've set the(LVS_OWNERDATA) style for it.
i've also read the following thread
<WTL: Reflect notifications to a control>
http://www.codeproject.com/script/Forums/View.aspx?fid=4486&msg=468889
my problem is somehow different
listview is wrapped by a WTL::CSplitterWindow class then the splitter is added to
MainFrame window, acutally the mainframe window is splitted into two views
i have reflected the message in mainframe class and i am processing it in
my view class ( which is inherited from WTL CListviewctrl) using
REFLECTED_NOTIFY_CODE_HANDLER(LVN_GETDISPINFO,OnGetDispInfoFileList)
DEFAULT_REFLECTION_HANDLER()
as the above mentioned thread reply says (by MIKE) mainframe message is reflected back ...
but i don't know if there is problem in splitterwindow class, which is in between
the listview and framewindow ...i don't know how to modify
splitterwindow( i suppose not ) because it is pre-written WTL class ...
my machine soft config is
WIN XP-SP2
DOTNET 2005 enterprise ed.
latest PSDK
IE 6
anyone if you know, could you tell me why 
Thanks in advance.
RAM
*********
|
|
|
|
|
problem is fixed !!!
As microsoft says, notification messages of child window is posted to parent window
here, my parent windows is a splitter so it needs a message feeder in order to convey all messages to top level window.
adding the following thing in the splitterwnd sets a pullstop to the problem..
FORWARED_MESSAGES()
RAM
** i've never seen a wand it gives anything **
** i am never going to deny it after seeing CP **
|
|
|
|
|
i got the same problem with you, i don't how to solve it. Anyone could help ?
|
|
|
|
|
Hi
I am trying to open a file for reading using C++ I/O. The call to read is simple
#include <fstream>
using namspace std;
int _tmain()
{
std::string infile(_T("testreport.txt"));
ifstream fin(infile.c_str(), ios::in);
if(!fin)
{
cout << "unable to open file for reading";
}
return 0;
}
when I execute the program I always get the failure. However if I specify the full path to the file like "d:\\testdata\\debug\\testreport.txt", I am able to open the file successfully.
I am using VC++ 2005 compiler and debugging with in VC IDE. How do I make VC++ to automatically take the relative path of the file.
This problem only occurs when I am debugging through the VC++ IDE.
Thanks and Regards
modified on Thursday, March 27, 2008 5:49 AM
|
|
|
|
|
psychedelic_fur wrote: How do I make VC++ to automatically take the relative path of the file.
First it has nothing to do with Visual C++. You are using a library called STL to open the file. It uses the OS support to open the file and they both support relative paths. But just like an absolute path you have to get the relative path correct or it won't work.
led mike
|
|
|
|
|
You have to configure your IDE to use d:\testdata\debug as working directory when debugging. On Visual Studio 2005, for instance, select Project->Properties menu item and then (on the newly appeared window) select the Configuration Properties->Debugging node, select Working Directory item (on the Local Windows Debugger) list and finally assign it the d:\testdata\debug path.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
|
psychedelic_fur wrote: Thank you
You're welcome.
psychedelic_fur wrote: It could probably be that MFC is setting the working directory automatically.
I don't think so.
Anyway now it works, why bother?
Best wishes.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
