|
epicyeti wrote: Is there a way I could effectively do this:
CString m_data = _T("...");
char data[];
data = m_data.GetBuffer();
Did you read the response from 2 hours ago?
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Yeah, I'm sorry I didn't respond.
the strcpy doesn't take a CString varriable. I could have used GetBuffer on it, but I would probably would have had to conver the returned wchar_t to a char like I ended up doing. My real issue evidently was with sending the SendRequest function a wchar_t* instead of a char*.
Thanks for your input, and again I am sorry I didn't respond.
|
|
|
|
|
epicyeti wrote: the strcpy doesn't take a CString varriable
It does because CString has an explicit LPCTSTR operator to do the casting. The problem is actually that you have UNICODE enabled (apparently), in which case you need to convert it from wchar_t to char* first. Alternatively, you could pass the data in UNICODE format, but you would need to pass the size as double the length of the string and specify that you are using UTF-16 as your text format in your HTTP headers.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Your signature is true to life. I'll be sure to know if I am using UNICODE from now on, and I'll be more careful with my headers. Thanks again for your input.
|
|
|
|
|
epicyeti wrote: SendRequest(LPCTSTR, DWORD, LPVOID, DWORD) function. the LPVOID parameter is the POST data that you send with a HTTP Post header.
You will probably need to do this:
CString strPostData = _T("Some POST Data");<br />
char buffer[100] = {0};<br />
strcpy(buffer, strPostData);<br />
pHttpFile->SendRequest("POST", dwSomeDword, (LPVOID)buffer, strlen(buffer) + 1);
LPVOID is defined as void*. Using the LPCTSTR operator for CString will return you a const char* (when UNICODE is not defined). The const keyword is the main thing you should be worried about there. The fact that SendRequest does not ask for a const void* indicates that it may try to write to that buffer, which would cause problems if you tried to pass in the CString object itself.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Are you trying to pass this to another function in the same thread or to another thread?
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
|
Hey guys,
I was wondering if we use iostream.h in visual studio 2005.
I tried including iostream.h but it says file cannot be found.
It's strange how iostream.h is not used in Visual Studio 2005
Are we suppose to have iostream.h in visual studio 2005
or do we use iostream.... using namespace std;
thanks
-- modified at 11:28 Tuesday 1st August, 2006
|
|
|
|
|
iostream.h is the old implementation (from before the standard was formalized). It was left in the old versions of the IDE for backwards compatibility only. You should be using iostream (the same goes for vector, list, map, string, etc.)
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
|
|
Hi,
I've written an own FindDlg. It's derived from CDialog and just provides an own SelectionList. It crashes anywhere between CFindDlg::EndDialog(IDOK) and the calling Method. - Ain't nice but happens.
But the prog crashes only while executing release-build. Running debug-release don't crash.  (Memory-Exeption during read...)
So how can I fix my prog, that it runs also within release-build. Or how can I find my bug? - I don't have any Idea?
Thanks && Greets,
Horst
Calling Method ==>
CFindDlg dlgFind;<br />
<br />
dlgFind.SetTreeRef(m_pobjCurrentTree);<br />
dlgFind.DoModal();<br />
MessageBox("You won't see me....");<br />
<br />
if ( ! dlgFind.GetFoundItem().IsEmpty() ) { <br />
LVFINDINFO SearchPattern;<br />
<br />
SelectTreeItem(dlgFind.GetFoundItem());<br />
<br />
SearchPattern.flags = LVFI_STRING;<br />
SearchPattern.psz = dlgFind.GetFoundItem();<br />
<br />
m_ctrlElement.SetItemState(m_ctrlElement.FindItem(&SearchPattern), LVIS_SELECTED, LVIS_SELECTED);<br />
m_ctrlElement.SetFocus();<br />
}<br /><== Calling Method
OnOK ==>
void CFindDlg::OnOK() {<br />
int iSelectedSOC;<br />
POSITION pListSelection = m_ctrlFoundItem.GetFirstSelectedItemPosition();<br />
<br />
iSelectedSOC = pListSelection == NULL ? -1 : m_ctrlFoundItem.GetNextSelectedItem(pListSelection);<br />
m_sFoundItem = iSelectedSOC == -1 ? "" : m_ctrlFoundItem.GetItemText(iSelectedSOC, 0);<br />
<br />
MessageBox("This will be the last you will see before abort...");<br />
EndDialog(IDOK);<br />
}<br /><== OnOK
|
|
|
|
|
|
Hotte wrote: dlgFind.DoModal();
MessageBox("You won't see me....");
This looks suspicious. Are you doing anything with m_pMainWnd?
Hotte wrote: Running debug...
F5 or Ctrl+F5?
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Hotte wrote: MessageBox("This will be the last you will see before abort...");
EndDialog(IDOK);
}
Have you tried calling CDialog::OnOK() instead of EndDialog?
Check to make sure you don't have a stack limitation set in your release build settings.
You say you are getting a memory exception during your read operation in the debug build, correct?
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Sir, Why Virtual Constructor doesn't exist ? Whereas we have virtual Destructor.What may be the reason for that?
pls give explaination for this as i am a bit confused.
bye Thank u.
Fly Like An Eagle With MIGHTY POWER.
|
|
|
|
|
if you know what virtual is made for, you would understand that the behavior of a type constructor shouldn't (actually, cannot) be changed/overriden by a child...
on the other side, destructors should always be virtual, so that when destructing a variable, it starts by the child destruction, and then, the base class destruction...
|
|
|
|
|
toxcct wrote: on the other side, destructors should always be virtual
Not always, just any time you are writing a class that is meant (or allows for) a class to be derived from it. The STL containers do not have virtual destructors because they are not meant to be base classes.
Basically, any time you have a virtual function in your class, you should declare your destructor as virtual.
As for the OP ... the way constructors work does not provide a need for virutal constructors. When an object is created, its allocation is started from the most base class and then works down towards the desired derived class. In other words, if you have a heirarchy where A is derived from B is derived from C, and you declare a variable of type A, the constructor for C is called, then B, and finally A.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: Not always, just any time you are writing a class that is meant (or allows for) a class to be derived from it. The STL containers do not have virtual destructors because they are not meant to be base classes.
Basically, any time you have a virtual function in your class, you should declare your destructor as virtual.
actually, this is what i meant. you're not obliged to put every dtors virtual, but as there's no pb to declare them virtual if their class is not derived, and as they should be virtual when the class is derived, then, ,it's more easy to always declare a destructor virtual... 
|
|
|
|
|
toxcct wrote: actually, this is what i meant. you're not obliged to put every dtors virtual, but as there's no pb to declare them virtual if their class is not derived
The only problem is that if there are no derived classes (or your class is not meant to allow for derived classes), it is a HUGE overhead to declare it virtual (which causes a v-table to be created for that object).
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: Basically, any time you have a virtual function in your class, you should declare your destructor as virtual.
I've always thought of this as a defect in C++, and yet another reason for people to say (rightly in this case) that C++ is too complex.
For legacy-code reasons it's probably too late now, but it really should have been an error if you 1) add a virtual function 2) write a destructor and not make it virtual.
|
|
|
|
|
matter of performances...
BTW, you'd better know what you do when you code, complex is the language or not
|
|
|
|
|
Warren D Stevens wrote: I've always thought of this as a defect in C++, and yet another reason for people to say (rightly in this case) that C++ is too complex.
For legacy-code reasons it's probably too late now, but it really should have been an error if you 1) add a virtual function 2) write a destructor and not make it virtual.
I've never really had a problem with this (and I have always failed to see why others have a problem with it). If you declare a function virtual in your class, make your destructor virtual as well. If you have no virtual functions, no need to declare your destructor virtual. I can't remember if Microsoft's compiler does this, but I do know that Intel's and GNU both give you a warning (when you have your warning level set to the highest setting) if you have a class with a virtual member function and no virtual destructor.
It should not be an error because it is valid (as far as the standard is concerned), but it is bad practice since it causes lots of bugs. If you made this into an error, you would have to do the same for things like using new without a corresponding delete.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
CodeVarma wrote: Why Virtual Constructor doesn't exist ?
Virtual implies partial information. In other words, only the interface is known as opposed to the exact object type. You need complete information about an object in order to create it.
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Hi to all,
How I can use "Tab Control" in a Dialog?
I had searched for it, but the method was to create a new Class inherited from 'CTabCtrl'.
Can't I use simple Member Variable for "Tab Control" of 'CTabCtrl' type in that Dialog?
Thanks & Best Regards,
Aniket Salunkhe
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
