|
It would be helpful if you showed the actual code that generated this message! It looks like a calling convention mismatch to me.
Steve
|
|
|
|
|
Here is the code snippet that generated the compilation error. The entire project can be downloaded from the codeproject article "Universal Progress Dialog".
INT_PTR CUPDialog::DoModal()
{
Cleanup(); //If this not first time, Terminate any previous instance Threads !!
return DialogBoxParam(NULL,MAKEINTRESOURCE(IDD),m_hParentWnd,ProgressDlgProc,(LPARAM)this);
}
I am not an experienced Windows programmer comming from the UNIX world so there is a lot of things that the author of the code is doing that I have never seen in MFC. One being that the function ProgressDlgProc (which is the fouth argument that is is puking on) is used without parameters being passed with it. Considering that the project compiled and ran on the authors machine I think there may be a library or include file or some parameter that needs to be set in the compiler settings. I just don't know. By the way, I am using Windows 2000.
Buck
|
|
|
|
|
I need to see the declaration and definition of "ProgressDlgProc" too.
Steve
|
|
|
|
|
ProgressDlgProc appears in only three places.
Here it is in the UPDialog.h file,
class CUPDialog
{
static struct _tagInitCommonControls
{
_tagInitCommonControls(); // Constructor to call the InitCommonControlsEx() function
}
m_InitCommonControls; // Static Variable
HWND m_hParentWnd; //The Window that Requested the Progress Operation; Needed to Create the DialogBox
bool m_bAllowCancel; //Should the Dialog allow PreEmtption by user before Completion?
HANDLE m_hThread; //Holds the Handle to the Created Thread
TCHAR m_szDialogCaption[256]; //Fill up with the Title of the DialogBox
CUPDUPDATA m_ThreadData;
friend INT_PTR CALLBACK ProgressDlgProc(HWND,UINT,WPARAM,LPARAM); //The Windows Message Procedure for the DialogBox
void Cleanup();
public:
enum { IDD = CUPDIALOG_DIALOG_ID };
CUPDialog(HWND hParentWnd,LP_CUPDIALOG_USERPROC lpUserProc,LPVOID lpUserProcParam,LPCTSTR lpszDlgTitle=_T("Please Wait.."),bool bAllowCancel=true);
virtual ~CUPDialog();
INT_PTR DoModal(); //Returns: IDOK => Sucessful; (IDCANCEL && HIWORD(wParam)==0) => Some Error in UserProc; (IDCANCEL && HIWORD(wParam)==1) =>User Cancelled the Dialog;
};
It also appears as the function itself,
INT_PTR CALLBACK ProgressDlgProc(HWND hDlg,UINT Message,WPARAM wParam,LPARAM lParam)
{
switch(Message)
{
case WM_INITDIALOG:
{
CUPDialog *pProgressDialog = (CUPDialog*) lParam;
if(pProgressDialog->m_bAllowCancel == false)
and also as a part of a return value which is what I posted and the compiler crashes on.
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
