|
dehseth wrote:
I do not suggest to get buffer pointer...and use it.
Actually you did.
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
dehseth wrote: and it's bad because?
Read the function documentation, you'll see why it is very bad to use it without knowing what it does.
EDIT: by the way, the GetBuffer returns a LPTSTR and the CString supports a cast operator to a TCHAR string also. So, if the conversion to a char* is not 'automatic', using GetBuffer won't solve the problem.
For more info, reaf the article I suggested in my other post.
modified on Tuesday, October 21, 2008 7:03 AM
|
|
|
|
|
dehseth wrote: GetBuffer()
GOD, another one who doesn't know what he's talking about !!! 
|
|
|
|
|
As usual, a link to the must read article[^] 
|
|
|
|
|
|
thanx for articles guys..
|
|
|
|
|
Try this:
//CString to char pointer
1.
CString MyString = "ABCDEF";
char * szMyString = (char *) (LPCTSTR) MyString;
2.
char *pBuffer = new char[1024];
CString strBuf = "Test";
pBuffer = strBuf.GetBuffer(sizeof(pBuffer));
IN A DAY, WHEN YOU DON'T COME ACROSS ANY PROBLEMS - YOU CAN BE SURE THAT YOU ARE TRAVELLING IN A WRONG PATH
|
|
|
|
|
"_$h@nky_" wrote: strBuf.GetBuffer(sizeof(pBuffer));
bloody hell, that's even worst than what was proposed earlier !!!
to make it short : NEVER USE GetBuffer() FOR A CAST PURPOSE !!
you made it good with (LPCTSTR) cast operator, stick with it !
and please, read the other answers before replying
|
|
|
|
|
"_$h@nky_" wrote: 1.
CString MyString = "ABCDEF";
char * szMyString = (char *) (LPCTSTR) MyString;
This is wrong: if UNICODE is not defined, you don't need any casts. If UNICODE is defined, the results will be completely wrong. Please read the article from Michael Dunn (see one of my previous replies) before answering such questions.
"_$h@nky_" wrote: 2.
char *pBuffer = new char[1024];
CString strBuf = "Test";
pBuffer = strBuf.GetBuffer(sizeof(pBuffer));
This is plainly wrong too, see the other replies.
Please read the previous answers before posting !
|
|
|
|
|
"_$h@nky_" wrote: //CString to char pointer
1.
CString MyString = "ABCDEF";
char * szMyString = (char *) (LPCTSTR) MyString;
2.
char *pBuffer = new char[1024];
CString strBuf = "Test";
pBuffer = strBuf.GetBuffer(sizeof(pBuffer));
Why not
3.
char *pBuffer;
CString strBuf = "Test";
pBuffer = (char *) &strBuf;
to go out with a bang?
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
[My articles]
|
|
|
|
|
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Here's a solution I've been using to this problem:
#define STOC(X) ((char *)(const char *)(X))
STOC stands for "String TO Char". You can't cast a CString directly to a char*, but you can do it in two steps. This has been working for me.
|
|
|
|
|
Alan Balkany wrote: Here's a solution I've been using to this problem:
Alan, the problem is not the conversion between char* and const char*.
The problem is that he's building with support for unicode and he's using the ansi version of strcpy(), which of course expects a const char*, but the CString object holds a wchar_t*.
The wide-string version of CString automatically converts to a const wchar_t*, which would be expected by the wide-string version of strcpy(): wcscpy().
Iain explained this in the first reply.
Regarding your suggested macro, I'm surprised to find that the stunt slips through the compiler; converting a const pointer to a non-const pointer....
I tried and actually succeeded to convert a CString object via the CSimpleString::operator PCXSTR(), which returns a const pointer to the string, to a wchar_t* and modify the string. 
I didn't think the compiler would let me do that and I'll treat it as a compiler bug. I mean, the whole idea behind a const type is that you're not allowed to modify it....
It's even worse than the const_cast<> keyword.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Dear friends,
My doubt is regarding the exception setting in Windows firewall.
I want to check (by code) whether a specified application is set as Firewall exception. I am trying to do it in VC6.
Is there any API for checking this?
Regards,
Krishnakumar
|
|
|
|
|
If you install Windows SDK there are lot samples for manipulating windows firewall. You can also try here[^].
-Saurabh
|
|
|
|
|
|
Dears friends,
I want to develop an application.
The input for the application is a COM dll filename.
The application will display (output of the application) whether the input COM dll is a registered one or not.
Could you please tell me how can i do this?
I mean how to identify the DLL is a registered one or not.
Regards,
Krishnakumar
|
|
|
|
|
It's not going to be easy. A dll get's registered by writing a registry entry with a GUID that points to the DLL. I'm not aware of any information that is the other way around.
For the ATL wizard DLLS, you could load the resources, search for GUIDs, and look them up, but that only works if people have used the ATL classes. Not always true...
About the only way I can see is to brute force it, by enumerating all the HKCR\CLSID subkeys, and see if any of them end up pointing to your DLL.
It can also be a nit more complex... They may not specify a full path, and may instead use just "mydll.dll", and let windows fill in the path for it.
Not much joy for you, sorry.
Iain.
|
|
|
|
|
Thanks for your information.
|
|
|
|
|
In addition to Iain's reply:
I don't see any other way than walking through the registered COM servers below the HKCR/CLSID registry key.
It also depends on what you mean by "registered".
Even though the server may be registered in terms of there is an existing entry in the registry below the HKCT/CLSID, its typelib and interfaces may not be registered properly. If you want to detect this as well you're in for a lot of grunt work.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Thanks for your information.
By the word "registered", I mean that whether the thing "regsvr32 mydll.dll" had been done or not.
|
|
|
|
|
Just to add... All that regsvr32 does it to look for a RegisterServer exported function in the DLL. What that function does is completely up to the writer of that DLL. It could do a LOT of things (typelibs, interfaces, registering its interface with various shell places...).
You may need to go back to basics, and ask what *you* mean by registered, and why you care. There may be a better method of getting to the solution of the actual problem you face.
Iain.
|
|
|
|
|
Krishnakumartg wrote: By the word "registered", I mean that whether the thing "regsvr32 mydll.dll" had been done or not.
Ok.
Let us elaborate on this for while...
Like Iain said, what "regsvr32" does is simply load the .dll-file with ::LoadLibrary(), get the entry address of the exposed function DllRegisterServer() with ::GetProcAddress() and finally call DllRegisterServer() in the library.
What that function does is entirely up to the library.
In case of COM servers in DLLs, the DllRegisterServer() function is assumed to add information about the objects and interfaces exposed from the library into the registry.
There's no guaranteed way of knowing what COM servers, interfaces and/or their GUIDs just by looking into the library. Different COM servers may be created with different tools, they may or may not have the typelibrary included as a resource in the library.
Even if you walk through the registry tree below the HKCR/CLSID key and enumerate all registered servers, you may find servers that reside in files with the same name as the one provided to the application, but you have no clue whether this might be a later version if the paths differ.
You also have to consider what to do if you come to the conclusion that the DLL provided to the application has not been registered.
Are you supposed to register it? Then you can save a lot of trouble and simply register it without checking whether it was previously registered or not.
Is the user supposed to figure out if this DLL should be registered? Based on what information? How could the user possibly know?
My point is that there's no safe way of figure out whether a certain DLL has been "registered" or not. And even if there was, it's unclear what should be done with the file.
BUT, if you have a handful of COM servers and you know their IDs and interfaces, you could try to create each one of them and if the creation fails with the error REGDB_E_CLASSNOTREG you know that it has not been registered yet.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Hi all,
I've build the whole solution of one of my C++ project in release mode. Compilation is fine, but when the exe is building it says that one of file is missing and Interface not registered
Can someone tell me how to solve this question.
Thanks a lot
I appreciate your help all the time...
CodingLover
|
|
|
|
|
I've never seen this message. Do you have any custom build steps in your project?
Iain.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
