|
Thanks. Actually its coming from an editbox so
mEdit.GetWindowText(myTExt);
char* newString = new char[myText.GetLength()+1);
so how do I make newString into a unicode string or the L("abc") like you said?
Thanks,
ns
|
|
|
|
|
If you have a CString, then it has a built in member to give you a BSTR,
namely
AllocSysString (done that way to avoid/promote confusion, I guess).
The BSTR contains a copy of the original string, so changes to the CString won't affect the BSTR, and remember that at some stage, you'll need to call SysFreeString and have it destroy the BSTR.
Steve S
[This signature space available for rent]
|
|
|
|
|
If I understood you, I tried this:
CString abc = "anb";
BSTR b_dataBaseName = SysAllocString (abc);
}
but got:
: error C2664: 'SysAllocString' : cannot convert parameter 1 from 'class CString' to 'const unsigned short *'
Thanks,
ns
|
|
|
|
|
myText.AllocSysString() will return a new BSTR for you. At least it did in VC6.
|
|
|
|
|
Your method worked. It compiles! I was using SysAllocString (also exists). Now question is how to free this?
I didnt see a FreeSysString or SysFreeString matching the AllocSysString.....?
I was told that SysAllocString MUST be followed by SysFreeString, so I'm looking for this sort of matching function to go with AllocSysString...
Thanks,
ns
|
|
|
|
|
Use SysFreeString.
Jason Henderson start page articles "If you are going through hell, keep going." - Sir Winston Churchill
|
|
|
|
|
MSDN says SysFreeString frees stuff made from SysAllocString. I used AllocSysString().OK. I found this in MSDN just now for AllocSysString :
In the rare case the client receiving the returned string does not free memory in the string, you might have to free it yourself by using ::SysFreeString.
MSDN contradicts itself (unless I misunderstand):
SysFreeString Parameters
bstr
Unicode string that was allocated previously, or NULL. <code>If NULL, the function simply returns</code>.
Return Values
None.
Remarks
Passing into this function any invalid and, under some circumstances, <code>NULL pointers will result in unexpected termination of the application.</code>
I wonder which statement is true....suggestions?
Thanks,
ns
|
|
|
|
|
If you are passing this BSTR into a function, the function will usually free it. That doesn't mean it will free it.
Use SysFreeString.
Jason Henderson start page articles "If you are going through hell, keep going." - Sir Winston Churchill
|
|
|
|
|
I thought that's what I'd written ....
Steve S
[This signature space available for rent]
|
|
|
|
|
I know this one has been asked before... so much so that CG wrote an article about it.
I need to do string formatting using std::strings.
The actual problem is this: I need "trace" methods with variable arguments.
void Trace(const char *szFormat, ...);
Using MFC, I can just use CString.FormatV() or whatever, but I can't see a way to do it with std::strings without parsing the format string myself.
So I'm thinking that I'm looking at the problem the wrong way. Can any of you think of a way to do what I want?
J
|
|
|
|
|
you can always use sprintf (and friends).
std::string stdStringFmt(const char* fmt, ...)
{
const int TBUFSIZE= 2000;
char tBuf[TBUFSIZE];
va_list argptr;
va_start(argptr, fmt);
_vsnprintf(tBuf, TBUFSIZE, fmt, argptr);
va_end(argptr);
std::string out = tBuf;
return out;
}
something like this..
-c
As always, it's bread and circuses. And while bread is down right now, circuses are way up.
|
|
|
|
|
That's what I have at present, but I'm trying to get around using sprintf at all.
J
|
|
|
|
|
sprintf is King.
even CString::Format uses a flavor of it.
-c
As always, it's bread and circuses. And while bread is down right now, circuses are way up.
|
|
|
|
|
In the words of the prophets:
Thou shalt foreswear the vile printf and all his horrid brethren.
J
|
|
|
|
|
You can assemble a std::ostringstream using the stream-operator <<, which is overloaded for almost any type.
To access the std::string , you would use CMyOStringStream.str() , and if you need the LPCTSTR , you would add .c_str() to convert the std::string into a dumb char array.
|
|
|
|
|
Right, but I want the caller to simply pass in one set of parameters with no lead up.
I could do this...
void Trace(std::ostringstream &s);
...
std::ostringstream traceMessage;
...
Trace(traceMessage << "Wankity wank with the number " << 7);
I think. But I'd have to make sure the stream is empty before each trace call.
J
|
|
|
|
|
Use sprintf. That's what pretty much everyone else uses. Trace code is going to be removed in Release mode anyway right?
Todd Smith
|
|
|
|
|
Todd Smith wrote:
Trace code is going to be removed in Release mode anyway right?
Hmmm. Probably not. It's not retail software. It's a one-off that I'm going to want a detailed trace when the damn thing crashes in the field.
Performance isn't really the issue. Readability is.
J
|
|
|
|
|
You are always going to have some sort of format string. C has no mechansism to tell what the types of the parameters in the ... part are, so you need a format string (or some other type of list) to let the function know what to grab off the stack.
--Mike--
Just released - RightClick-Encrypt v1.4 - Adds fast & easy file encryption to Explorer
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
I did
CTest myTest;
myTest.SetWindowText("abc"); <code>debug asserts here</code>
int nret = myTest.DoModal();
However if I do SetWindowText("abc"); in the InitDialog() of the CDialog class (CTest), it works fine.
Why cant we set the caption in the view class which spawns the dialog?
Thanks,
ns
Thanks,
ns
|
|
|
|
|
Your dialog doesn't exist as a window yet in the context you're trying to set its caption. There is no m_hwnd yet and so the call to SetWindowText kicks out. It's not until you call DoModal() that your window is created. If you want to set the caption prior to it even existing, throw in a string member variable in your CTest class and set it like you are with SetWindowText, except write some other cool function:
class CTest : public CDialog
{
private:
CString m_strCaption;
public:
....
SetCaption( const char *szCaption )
{
m_strCaption = szCaption;
}
};
DoStuff()
{
CTest myDlg;
myDlg.SetCaption( "Cool caption" );
myDlg.DoModal();
}
Then call SetWindowText in your OnInitDialog(), passing in your new m_strCaption variable.
Ty
"The significant problems we face cannot be solved at the same level of thinking we were at when we created them." -Albert Einstein
|
|
|
|
|
Thanks for the very detailed and informative solution. I was going to set some global flag to communicate between the view class and dialog, but definitely your way is the way to go! APpreciate it,
Thanks,
ns
|
|
|
|
|
So we are limited only to functions that dont have any cDialog controls in them.
We cant do
CTest myTest;
myTest.DoStuff();
myTest.DoModal();
where
CTest::DoStuff()
{
m_editInCTest.SetWindowText("a");
}
right?
So the functions we can call are only for setting variables in the CTest.
Just making sure,
Thanks,
ns
|
|
|
|
|
Yeah, this is the same as calling SetWindowText() directly. You can't do it either way because your window doesn't exist yet. You have to squirrel away the variable for use later on, once the window does exist.
You can always call other functions of CTest, just not any that deal with windows Which pretty much limits you to DoModal() and anything you've written yourself.
Here's what is really happening under the hood. SetWindowText() is an immediate action that needs to occur. This is also an MFC-specific function in CWnd. MFC handles this particular action by sending a low-level windows message, likely via the SendMessage() API call, named WM_SETTEXT. SendMessage() only works when you specify a valid handle to a pre-existing window. Your window doesn't exist yet, so this parameter would be NULL.
If you called SendMessage() yourself with a NULL parameter, the result is probably undefined. It likely just goes nowhere. MFC is protecting you from this unfortunate situation by kicking out an ASSERT and gently reminding you that you can't do this yet. SetWindowText and the many other MFC functions of CWnd are just protective wrappers around the Win32 API. If you didn't get this ASSERT, you'd never know that your caption wasn't being set properly, and you'd be looking all over the place trying to figure out why. God bless MFC
Hope this helps-
Ty
"The significant problems we face cannot be solved at the same level of thinking we were at when we created them." -Albert Einstein
|
|
|
|
|
Hey thanks for that deeper insight! Yep - MFC is cool.
Thanks,
ns
|
|
|
|