|
Firstly, the error seems to indicate that the return types don't match. Change all the INT_PTR return types in your "ProgressDlgProc" functions to int . After you’ve done that let me know the effect it has. It still looks a calling convention mismatch may remain.
Steve
|
|
|
|
|
Thanks, that took care of the typing problem with the compiler. There are two functions that are not defined. One is named SetWindowLongPtr(hDlg,GWL_USERDATA,(LONG_PTR)pProgressDialog); and the other is named GetWindowLongPtr(hDlg,GWL_USERDATA); But after looking at the Microsoft docs and that these functions superceded the 32 bit versions, I lopped off the Ptr part of the function name and everything was okay. Just a note, the docs mention that the declarations are in Windows.h but if you put the include in the StdAfx.h file the compiler complains that it has already included the file. There also is a User32.lib file in my library directory that visual studio is looking in.
|
|
|
|
|
It's strange that INT_PTR had to be replaced with int , although that was what the error message indicated. I suspect that the fact you had to do this indicates a fault in the library you're using. Have you got a link to the code for this "Universal Progress Dialog"?
Steve
|
|
|
|
|
I am trying to use pointers to create 3 list boxes in the main window of an application. I can get the first list to work fine, but if I even try to allocate memory for the second pointer (CListBox *Ptr2 = new CListBox(); ), the program gives me a run-time error. Anyone have any ideas?
|
|
|
|
|
If the denominator is zero you will get a divide by zero runtime error, check the denominator before calling the division operator.
(Or was it some other runtime error, you did not specify which so I just took a wild ass guess)
You may be right I may be crazy -- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
I'm not entirely sure what the runtime error is. A dialog pops up that says:
The instruction at "0x7c910e03" referenced memory at "0x00000001". The memory could not be "written"
Click on OK to terminate the program.
|
|
|
|
|
That would have been so cool if you were right
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
Show some code......
Steve
|
|
|
|
|
Here is the function:
void CRatiosWin::InitializeVariables()
{
SetFilePath("");
SetTimeParameterStatus(false);
SetFilePathStatus(false);
CListBox* listPtr = new CListBox();
listPtr->Create(WS_CHILD|WS_VISIBLE|WS_VSCROLL|WS_HSCROLL,CRect(0,0,400,400),this,IDC_LIST);
CListBox* listPtr2 = new CListBox();
listPtr2->Create(WS_CHILD|WS_VISIBLE|WS_VSCROLL|WS_HSCROLL,CRect(410,0,800,400),this,IDC_LIST);
fstream infile;
infile.open("VariableNames.txt",ios::in);
string var_name, rType;
VariableStringsListLength = 0;
while(infile>>var_name>>rType)
{
VariableStringsList[VariableStringsListLength++] = new CRatiosVariableStrings(var_name,rType);
}
}
If I make only one list box, it works fine, but if I add a second one, it screws up.
|
|
|
|
|
Another potential error is that both your list boxes have the same ID; IDC_LIST. They should be different.
You may be right I may be crazy -- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
SON OF A B****!!!
I was looking through other parts of the code and found the problem somewhere else! As it turns out, that run-time error simply refers to an array index out of bounds error (not quite a divide-by-zero, but )
I don't even know why this only came up when I added list boxes, the array had nothing to do with them.
Anyway, sorry for wasting your time.
|
|
|
|
|
I am having some weired situation going on in my VC++ program when I allocate and deallocate memory wihtin the application. Lemme explain the scenario, I am having an applicaiton where I allocate memory to a variable (which are initialized to NULL when the program starts) whenever the user requests and only deallocates it when the user requests the same variable again where I reallocate the memory again. But when I deallocate the memory it is not releasing the whole memory that I have allocated it before.
For example-
My program starts with total mem usage of 92596 bytes (At this point I haven't allocated any memory to those variables)
When I allocate memory to the first variable using either GlobalAlloc or VirtualAlloc it increases by 94752 bytes which equals to ~2000bytes
When I deallocate the memory using either GlobalFree or VirtualFree it is deallocating only half of the memory ~1000bytes
Now When I reallocate the memory in the same way as above, it is allocating new 2000bytes.
So, in this way slowly the memory being used by my program is increasing drastically after a while, as I sometimes allocate about 225 variables of ~2000bytes each.
But when I deallocate the memory of the same variables when I am exiting the application it does deallocate ~2000bytes of each variable.
Is there something I am doing wrong??
thanks.
-Pavan
|
|
|
|
|
pavanbabut wrote: Is there something I am doing wrong??
As long as you are freeing all memory that you allocate, then no
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
You can make calls to GetProcessWorkingSetSize and GlobalMemoryStatus to see if the numbers are changing.
|
|
|
|
|
Whenever I check it, it is freeing only half of the allocated size. But it frees the whole allocated memory when I deallocate it at the time of terminating the application, not while 'm running the application.
-Pavan.
|
|
|
|
|
How are you checking this? There's no accurate way that I know of.
Try this if you'd like:
MEMORYSTATUS OrigMemoryStat;
::GlobalMemoryStatus(&PrevMemoryStat);
TRACE(_T("********************************\n"));
for (int i = 0; i < 100; ++i)
{
HGLOBAL hGlobal = ::GlobalAlloc(GHND, 2000);
::GlobalFree(hGlobal);
MEMORYSTATUS MemoryStat;
::GlobalMemoryStatus(&MemoryStat);
TRACE(_T("********************************\n"));
TRACE(_T("** Delta dwAvailPhys %li Bytes\n"), (long)MemoryStat.dwAvailPhys - (long)OrigMemoryStat.dwAvailPhys);
TRACE(_T("** Delta dwAvailVirtual %li Bytes\n"), (long)MemoryStat.dwAvailVirtual - (long)OrigMemoryStat.dwAvailVirtual);
}
TRACE(_T("********************************\n"));
Trust the OS
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
Ok, I figured out the problem. Once I allocate the memory, I am saving data into the variable by calling another function, in this process I am allocating more memory to another variable to hold a bitmap data, which is not being deallocated later and its piling up.
-Pavan.
|
|
|
|
|
|
Nice article... thanks..
|
|
|
|
|
|
Anil K P wrote: While trying, I get it as RGB(205,205,205) which is White.
More of a gray.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Anil K P wrote: I need to get the background color of an active window. While trying, I get it as RGB(205,205,205) which is White
How are you doing this?
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
Anil K P wrote: RGB(205,205,205) which is White
wrong, white is RGB(255, 255, 255)
|
|
|
|
|
|
Bookmarked/Favorited. Thanks!
Mark
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|