|
Mark Salsbery wrote: but using _T() in that fashion is incorrect.
I can't believe you got that far, I stopped looking after seeing this bowl of worms:
try<br />
{<br />
TRY<br />
{<br />
do <br />
{
led mike
|
|
|
|
|
Come on, Mike, it's the old adage, "If at first you don't succeed, try and try again." 
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
LMAO
It must be the Texas version: "try and try and do, can't be fooled again".
led mike
|
|
|
|
|
You should post that code to the Coding Horrors one.
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
|
|
|
|
|
 ROTFL. I am just wondering why people like Mark, David, etc., are making fun of the OP. Crazy guys. Your reply is the only one which makes sense. 5 for that.
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
I get the same results when I remove _T().
Yes, I'm reading data synchronously.
I tried writing to the CString character by character too, but it threw the exception at the first character.
for(nTestIndex = 0; nTestIndex <= dwSize; nTestIndex++)
{
m_strResponse += pszOutBuffer[nTestIndex];
}
|
|
|
|
|
m_strResponse should really be a CStringA, not a CString.
Then, maybe try stepping into the CStringA += operator code to see why an exception
is being thrown.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Why CStringA? MSDN doc says CString does both ANSI and Unicode, while CStringA does just ANSI. Why would that make a difference?
Stepping through code not exactly an option... Long story, but this is old code (5 yrs) that mysteriously broke at that point when I made a change to the request xml. In other words, this code worked before, but doesn't anymore. I suppose I could write a small test for that one line, but http connection won't work from my testing environment.
|
|
|
|
|
habs wrote: Why CStringA?
To match your incoming data. If the data is coming in Unicode, then use CStringW.
Any other case requires potential conversion of the data, depending on your build configuration.
Is the debugger no help? There's not all that many reasons the CString += operator
should fail.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
The following test code works without any issues:
int main(int argc, char* argv[])<br />
{<br />
char * pszOutBuffer;<br />
pszOutBuffer = "test";<br />
CString m_strResponse;<br />
m_strResponse += CString(pszOutBuffer);<br />
<br />
<br />
printf(m_strResponse);<br />
<br />
<br />
return 0;<br />
}
I added all this header info from the original program:
#include <afxwin.h>
#include <afxext.h>
<br />
#ifndef _AFX_NO_OLE_SUPPORT<br />
#include <afxole.h>
#include <afxodlgs.h>
#include <afxdisp.h>
#endif // _AFX_NO_OLE_SUPPORT<br />
<br />
<br />
#ifndef _AFX_NO_DB_SUPPORT<br />
#include <afxdb.h>
#endif // _AFX_NO_DB_SUPPORT<br />
<br />
#ifndef _AFX_NO_DAO_SUPPORT<br />
#include <afxdao.h>
#endif // _AFX_NO_DAO_SUPPORT<br />
<br />
#include <afxdtctl.h>
#ifndef _AFX_NO_AFXCMN_SUPPORT<br />
#include <afxcmn.h>
#endif // _AFX_NO_AFXCMN_SUPPORT<br />
<br />
#pragma warning ( push )<br />
#pragma warning ( disable : 4786 )<br />
#include <map><br />
#include <string><br />
#include <strstream><br />
#include <fstream><br />
<br />
std::ostream& operator<< ( std::ostream& os, CString& cs );
I'm having trouble switching this to CStringA... Did I mention this is Visual Studio 6.0?
|
|
|
|
|
Almost always, if you use a catch-all you should re-throw the exception again.
Steve
|
|
|
|
|
I'm assuming that none of you know the answer or have anything helpful to say since you have resorted to making fun of this code... (apologies to Mark, who at least seems to be trying)
I added the extra try{}catch(...){} because the macro didn't catch the exception, and I didn't know if just adding catch at the end of the macro would work. I also tried adding catch(CException &e), but that didn't catch anything. I don't know to get to the exception that is caught in the (...), and GetLastError() only returns 0. I have pulled the assignment code out and put it in a separate program (see above), and it works fine.
This lovely little segment of code even worked before, but doesn't work anymore (yay, maintenance).
So anyways, unless you know how to tell me how to get at the exeception, or how to debug, or how to fix... bug off.
modified on Thursday, March 27, 2008 10:04 AM
|
|
|
|
|
habs wrote: I'm assuming that none of you know the answer or have anything helpful to say since you have resorted to making fun of this code
Speaking only for myself here. Since I am not being paid to analyze that monkey crap you posted I didn't even try to "know the answer". My answer ( and based on the history around here I choose not to post) would be, if I had to maintain that monkey crap, to select the entire thing and press the delete key. Then develop a reasonable solution from scratch.
led mike
|
|
|
|
|
You haven't provided enough evidence that the diagnosis of the problem is correct.
You might try to:
- replace the TRY-CATCH_ALL macros
- use a try-catch on the "Read the Data" block rather than the whole function
- properly handle the case of WinHttpQueryDataAvailable failure.
- verify that m_strResponse is valid before you attempt to concatinate to it.
It may have "worked" before; I would add "by the grace of God." The code is flawed.
|
|
|
|
|
Thanks for some suggestions. I'm not certain how to implement all of them.
Member 754960 wrote: - properly handle the case of WinHttpQueryDataAvailable failure.
Are you talking about missing a return false; ? I can add that in, but I actually get a response, dwSize 753, so I don't think that's the problem.
Member 754960 wrote: - verify that m_strResponse is valid before you attempt to concatinate to it.
How would I validate m_strResponse?
|
|
|
|
|
AFAICS, on WinHttpQueryDataAvailable failure dwSize is undefined; it may be 0; it may be junk. You haven't indicated if that call failed or not. In that case, it is not clear what awful behavior happens if you then call WinHttpReadData. Why waste time chasing phantom cases? Just remove the bogus pathway.
Unless you are using the debugger to examine dwSize, I don't see it being output anywhere. I have to wonder what the difference is between dwSize and dwDownloaded. What is supposed to happen when they are different?
The symptom you report is that an often used operation of a common type generates an exception. The object is a class member that is neither initialized or reset in the function that generates the exception. You might want to examine how this object is used before the call to the function. Is it being locked? Is there a call to GetBuffer/ReleaseBuffer? etc.
You should be able to trace into the CString class and determine the exact cause of the exeption.
|
|
|
|
|
hmmmn
There is this line of code called several lines above:
if ( WinHttpWriteData( hRequest, (void*)m_strXMLMessage.GetBuffer(0), m_strXMLMessage.GetLength (), &dwBytesWritten) )
and no corresponding ReleaseBuffer.
Looking into that...
man, I'm getting cross-eyed. that was m_strXMLMessage and not m_strResponse, which doesn't have a GetBuffer call. 
modified on Thursday, March 27, 2008 5:27 PM
|
|
|
|
|
Hi, here's my problem:
I have a pointer to a struct (in C++, using VC++ .NET 2005 with MFC). The struct has been allocated from heap memory and contains many fields that are also allocated from the heap (character arrays, etc).
How can I copy this straight to another struct?
These are the two things I've tried, neither have worked:
This is where oldData is a pointer to a MyStruct that has been allocated from the heap:
struct MyStruct *newData = new MyStruct;<br />
memcpy(newData, oldData, sizeof(struct MyStruct));<br />
memcpy(oldData, newData, sizeof(struct MyStruct));<br />
delete newData;
And:
struct MyStruct newData;<br />
newData = *oldData;<br />
oldData = &newData;
Neither of these methods work. Is there a way to do this or do I have to copy field by field with the proper memory allocations in newData etc?
Thanks!
KR
|
|
|
|
|
It seems like it works if I copy all of the character arrays and heap allocated data separately and then do a memcpy on all the rest. Let me know if anyone knows a better way, please!
Thanks!
KR
|
|
|
|
|
KellyR wrote: Neither of these methods work.
No surprise there, since memcpy() has no way of getting to that other heap data. It only knows about the data in the MyStruct structure.
KellyR wrote: Is there a way to do this or do I have to copy field by field with the proper memory allocations in newData etc?
I would implement an assignemnt operator in the structure:
const MyStruct& operator=( const MyStruct &b )
{
...
return *this;
}
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Hi!
How can I realize whether a certain process is running or not?
(I mean the simplest way)
|
|
|
|
|
Usef Marzbani wrote: (I mean the simplest way)
thanks for clarifying that because normally I always look for the most difficult way to do things. 
This is the simplest way[^] I know of.
led mike
|
|
|
|
|
Well, who wants to know. Another Process? The Same Process, Why?
Version 1.
I did something years ago like this as follows. It assumes that the name of the Exe was not changed, and that we know where it lives. First try to get the File Attributes. If that works, you know the file exists, and that it still lives were you expected it. Now try to change the Name (to it's own Name). This will fail if it's in use. An exe is typically in use when it's running. (Also ofcourse if someone just opened it in a Binary Editor, but most end users don't have those things anyways).
That's simple, but hardly robust.
Version 2.
As soon as your process starts, create a Globaly Named Object (Mutex, Semaphore) but do not claim exclusive ownership, unless if you want to ensure that only one copy runs at anyone time. To determine later whether the process is running, try to create the same Globaly Named Object, but now with exclusive access. This will fail if the object already exists ( i.e. the process is running).
Version 3.
Read Matt Pietrecks dissertations, and spelunk into the inner workings of the Kernel.
Bram van Kampen
|
|
|
|
|
i have a console apllication *.cpp i am using VC++ 6.0 can any one help be by telling how to import only a *.DLL file step by step
Ahmad Sabry
|
|
|
|
|
If you have the "LIB" file of your DLL, just open the work space (or solution explorer in VS 2005), right click on your project name and add the LIB file.
this way is called "static linking".
else you can use "LoadLibrary()" API, defining the path and name of the DLL.
The second way is called "dynamic linking".
In the second alternative, you must use "GetProcAddress()" API to use functions exported from DLL.
Any way, why don't you use MSDN.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
