|
Why do you want to detect your memory leaks in release mode ? I don't release understand that 
|
|
|
|
|
Ideally, you check memory leaks in debug mode and then finally change to release mode.
Are you writing configuration specific code?
If not you should be fine with checking leaks in debug mode.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
Debug-Mode is suitable for detect memory leaks.
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
Hi
i Have a ClistCtrl and i want ot display the gridlines only for the rows and not for the colums. i have extended my style using the LVS_EX_GRIDLINES property. how to achive this?
Thanks in Advance
Gokul
|
|
|
|
|
Here is an article called Drawing horizontal and vertical gridlines[^], which is a very old one used to draw grid lines in a list control before it supported the LVS_EX_GRIDLINES style.
Change it to draw only lines for the rows.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
how to convert
IPictureDisp *pIPictureDisp to Byte array.
VIBIN
"Fool's run away,where angle's fear to tread"
|
|
|
|
|
You could try the GDI function GetObject[^] after getting the GDI handle using the HANDLE property of IPictureDisp.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
Recently i have converted my project to VS2008 from VS2005.
My application crashes when we try to open a new job file from 'open' command.
Actually we have derived CFileDialog and added a preview on the right side of dialog.
So that when selecting the job iteself we can see the preview of it.
this works fine in VS2005. But it seems some problem after converting to VS2008.
Any solution to solve this problem.
Crashes in Vista machine alone. In Xp it works fine.
modified on Wednesday, August 19, 2009 2:42 AM
|
|
|
|
|
The crash is most likely a problem with the preview on the right side.
You should debug it and zero in on the problem.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
It works fine in XP machine after VS2008 migration.
But it dint work in Vista machines.
|
|
|
|
|
You shoul set
BOOL bVistaStyle = FALSE
in your derived class's constructor.
|
|
|
|
|
yes i have done that. It works fine.
|
|
|
|
|
Hi all
I am inserting files into SQL server using bulk insertion.
Can anybody tell me how to do it using variables.
I will store the data in a structure and how to insert this
structure to the SQL server.
Inserting using files is taking time.
Please help.
Regards
Deepu
|
|
|
|
|
Is this related to C++/MFC?
There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal
|
|
|
|
|
type:IMAGE
it's my pleasure to make friend with you.
|
|
|
|
|
Hi there
I have just discovered that CStdioFile does not "work correctly" with files bigger than 2^32 bytes. Everything works fine in my program using CStdioFile, until the file size gets up to the limit. (Opening the large file with CFile and doing GetLength() gives the correct value, doing the same with CStdioFile gives garbage, and Seeks to the end crash out with a bad seek exception.) The MSDN site where I discovered this limit says "use CFile" instead. However, CFile is unbuffered, and I need to do quite a bit of skipping around with small reads and writes. I was only using CStdioFile because of its buffering - I'm reading/writing binary data.
Short of writing my own buffer, any ideas? Is there likely to be a big performance hit if I just use CFile instead? Would you advise using CArchive (which I believe is buffered), or is the overhead not worth it?
Thanks for any ideas.
Bill H
|
|
|
|
|
You will probably need to implement buffering yourself, unless there is some third party class.
CArchive is used for serialization and moreover you need a CFile object to work with CArchive.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
Bill Heitler wrote: and I need to do quite a bit of skipping around with small reads and writes.
Traditional buffered I/O is terrible for this. It means you will keep filling and flushing the buffer. You are better off writing an algorithm tailored to your needs.
|
|
|
|
|
Good point - I'm sure you're right in principal about the buffering. Although I suppose it must depend on how close together the data locations are.
Just for interest I ran a very quick-and-dirty measure of the time to write then read 100,000 consecutive single floats. With CStdioFile it took 0.343 s, with CFile it took 3.348 s, and constructing a CArchive from the CFile and flushing and closing between the write and read, it just took 0.152 s. So I guess the buffering of CArchive makes a difference, at least for consecutive operations. But I don't know whether CArchive also has the 2^32 file size limit of CStdioFile. Does anyone else?
|
|
|
|
|
I have in a C++ module a for loop that can take some minutes to complete. I would like to add a pause/resume feature, and would also like to be able to stop it. However while the loop is running the program is totally unresponsive. Is there anything to be done ?
Raymond Mercier
|
|
|
|
|
Move the loop into a background thread and on each iteration (or every nth one) check for a "pause" flag that can be set by the UI thread; just be sure it is done in a thread-safe manner.
|
|
|
|
|
Thanks, but I have so little experience with threads, I will have to bone up on it.
Raymond
|
|
|
|
|
For dialog boxes, you can add and periodically call the following. Adjust to get best responsiveness:
BOOL CMyDialog::Pump()
{
MSG msg;
while (::PeekMessage (&msg, NULL, 0, 0, PM_NOREMOVE))
{
if (!AfxGetApp()->PumpMessage())
{
::PostQuitMessage(0);
return FALSE;
}
}
LONG idle = 0;
while (AfxGetApp()->OnIdle(idle++));
return TRUE;
}
|
|
|
|
|
Thanks, but I don't see how that can be made to deal with a loop.
Raymond
|
|
|
|
|
In the loop you periodically call the function; this keeps the message pump going and allows messages to be processed. This is the traditional way to make a progress/cancelable dialog box.
The alternative, and preferable for anything lengthy, is to run the operation in a thread.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
