|
Hi there,
You should look at CTimeSpan. (CTime - CTimeSpan = CTime...)
CTimeSpan has a function called GetTotalSeconds(),
example:
CTimeSpan myDiff(0,1,0,0); // 0 Days, 1 Hour, 0 Min, 0 Sec
ASSERT (myDiff.GetTotalSeconds()==3600);
hope this helps
Olli
|
|
|
|
|
Hello,
I have a program written in Visual C++ and I want to add some codes that can help me know
this program is being debigged (ex: in debug mode in Visual C++ ) in run-time.
Does anybody know how to do that ?
|
|
|
|
|
there is _DEBUG macro if your project's active configuration [Build->Set Active Configuration]is derived from Debug.
So you can check like this
#ifdef _DEBUG
//Run this code if in debug mode
#else
//Run this code if not in debug mode
#endif
|
|
|
|
|
|
There's a function you can call. I forget the name but it's something like IsDebuggerEnabled().
|
|
|
|
|
I get crappy things when I try and return a CString. It goes a little like this...
CString lotsofcrap;
blah blah
return lotsofcrap;
ERROR Unhandled exception...yadda yaddda
CString::CString(const CString& stringSrc)
{
ASSERT(stringSrc.GetData()->nRefs != 0); //**** DEBUGGER GOES TO THIS LINE
if (stringSrc.GetData()->nRefs >= 0)
{
ASSERT(stringSrc.GetData() != _afxDataNil);
m_pchData = stringSrc.m_pchData;
InterlockedIncrement(&GetData()->nRefs);
}
else
{
Init();
*this = stringSrc.m_pchData;
}
}
------------------------------------------------------
Why do it now when you can put it off and do it tomorrow?
|
|
|
|
|
|
K....
CString CLUPort::BuildStartCommand()
{
LUMessage msg;
CString strConnect;
memset(&msg, 0, sizeof(LUMessage));
msg.start.cmd = START;
msg.start.crc16 = crc16_checksum((byte_t *)&msg, sizeof(msg.start) - 2);
msg.start.crc16 = TO_buint16(msg.start.crc16);
memcpy(&strConnect, &msg, sizeof(msg.start));
return strConnect;
}
|
|
|
|
|
It's the memcpy bit - you need to get a pointer to the buffer and store data there rather than over the string object itself. See GetBuffer (I think) - also don't forget you need to make sure the buffer is of the correct length.
> Andrew.
|
|
|
|
|
Ok a little bit of reading convinces me that's the correct way to do this. However I don't understand what the buffer length is/should be. MSDN describes it to be "The minimum size of the character buffer in characters. This value does not include space for a null terminator." Eh?? Does this mean I need to specify a number greater than the largest possible length of the string-to-be?
|
|
|
|
|
The problem is in the memcpy()
You can't asign the mem to a CString
cheers!!!
Carlos Antollini.
|
|
|
|
|
You have overwritten CString object with LUMessage struct contents. CString is a C++ class, you can't write to CStrings using memcpy.
I have no idea what are the members of LUMessage (crc16 suggests ints) - you should convert them to strings and concatenate them in strConnect.
Tomasz Sowinski -- http://www.shooltz.com.pl
|
|
|
|
|
Version II:
CString CLUPort::BuildStartCommand()
{
LUMessage msg;
CString strConnect;
LPTSTR pBuffer = strConnect.GetBuffer(1);
memset(&msg, 0, sizeof(LUMessage));
msg.start.cmd = START;
msg.start.crc16 = crc16_checksum((byte_t *)&msg, sizeof(msg.start) - 2);
msg.start.crc16 = TO_buint16(msg.start.crc16);
memcpy(pBuffer, &msg, sizeof(msg.start));
strConnect.ReleaseBuffer();
return strConnect;
}
This seems to only copy msg.start.cmd into strConnect, but I need the whole msg.start struct...
|
|
|
|
|
Hi,
Replace this;
strConnect.GetBuffer(1);
with;
strConnect.GetBuffer(sizeof(msg.start));
Hope that helps.
> Andrew.
|
|
|
|
|
Been there, done that. Whether I put 1, 100, or sizeof(msg.start) I get the same result each time. pBuffer seems to get the value of only msg.start.cmd instead of all of msg.start.
|
|
|
|
|
Without information about the data types of LUMessage struct nobody here will be able to help you.
Tomasz Sowinski -- http://www.shooltz.com.pl
|
|
|
|
|
There may be a zero byte after msg.start.cmd, this will cause ReleaseBuffer() to cut the string at that point.
|
|
|
|
|
One suggestion:
Instead of returning a CString, I would suggest passing one as a parameter by reference and manipulating it. Also, memcpy doesn't work well with CString (too much detail involved in explaining why -- basically, the memory structure is different than a normail C-style character arrary).
Zac Howland
|
|
|
|
|
> One suggestion: Instead of returning a CString, I would
> suggest passing one as a parameter by reference and manipulating it
Why? CString uses copy-on-write - the cost of copy constructor call is very low (no memory allocations are performed).
Tomasz Sowinski -- http://www.shooltz.com.pl
|
|
|
|
|
I disagree, we had a serious performance problem that was caused by
passing CStrings into a method by value rather than by reference.
Pass by value implies use of the copy constructor. Performance was increased dramatically by using pass by reference. I didn't do the work, but it
made such a difference the entire department was told about it.
Stephen Kellett
--
C++/Java/Win NT/Unix variants
Memory leaks/corruptions/performance/system problems. UK based.
Problems with RSI/WRULD? Contact me for advice.
|
|
|
|
|
> I disagree, we had a serious performance problem that was
> caused by passing CStrings into a method by value rather than
> by reference.
> Pass by value implies use of the copy constructor.
CString's copy c'tor only increments a counter using InterlockedIncrement. No memory allocations are made. Unless the function was called in very tight loop millions of times, there should be no noticeable difference.
Or maybe it was before MFC 4.0? I believe they've implemented copy-on-write in this version.
Tomasz Sowinski -- http://www.shooltz.com.pl
|
|
|
|
|
TRY THE FOLLOWING:
CString CLUPort::BuildStartCommand()
{
LUMessage msg;
CString strConnect;
int nSize = sizeof(msg.start) + sizeof(TCHAR) ; //<-------------
LPTSTR pBuffer = strConnect.GetBuffer(nSize);
memset(&msg, 0, sizeof(LUMessage));
msg.start.cmd = START;
msg.start.crc16 = crc16_checksum((byte_t *)&msg, sizeof(msg.start) - 2);
msg.start.crc16 = TO_buint16(msg.start.crc16);
memcpy(pBuffer, &msg, sizeof(msg.start));
strConnect.ReleaseBuffer(nSize); //<---------------
return strConnect;
}
Mh2!
|
|
|
|
|
MDI applications begin with a blank window by default. What code creates this, and how can I prevent it from opening immediately? There are certainly programs that open up without a blank window, such as Photoshop. thanks-
Jake
|
|
|
|
|
Change your application's InitInstance:
CCommandLineInfo cmdInfo;
ParseCommandLine(cmdInfo);
if (CCommandLineInfo::FileNew == cmdInfo.m_nShellCommand)
{
cmdInfo.m_nShellCommand = CCommandLineInfo::FileNothing;
}
Tomasz Sowinski -- http://www.shooltz.com.pl
|
|
|
|
|
Hello Jake,
I suppose you've created a MDI application using the VC++ Wizard.
In this case, the creation of the first initial document is performed by
ProcessShellCommand(cmdInfo) in the main of your program.
If you check the docs, you will find that next code:
----
// Parse command line for standard shell commands, DDE, file open
CCommandLineInfo cmdInfo;
ParseCommandLine(cmdInfo);
// Dispatch commands specified on the command line
if (!ProcessShellCommand(cmdInfo))
return FALSE;
---
will handle the passed arguments when you execute the application. You can override these by writing your own command-line parsing stuff.
The default behaviour of ProcessShellCommand is when not passing parameters with your application: "Start appl. and open new document".
Hopes this helps,
EiSl
|
|
|
|