|
FROM MSDN
Antony M Kancidrowski wrote:
In the debug version of MFC, the VERIFY macro evaluates its argument. If the result is 0, the macro prints a diagnostic message and halts the program. If the condition is nonzero, it does nothing.
The diagnostic message has the form
assertion failed in file <name> in line <num>
where name is the name of the source file and num is the line number of the assertion that failed in the source file.
In the release version of MFC, VERIFY evaluates the expression but does not print or interrupt the program. For example, if the expression is a function call, the call will be made.
In the debug version of MFC, the VERIFY macro evaluates its argument. If the result is 0, the macro prints a diagnostic message and halts the program. If the condition is nonzero, it does nothing.
The diagnostic message has the form
assertion failed in file <name> in line <num>
where name is the name of the source file and num is the line number of the assertion that failed in the source file.
In the release version of MFC, VERIFY evaluates the expression but does not print or interrupt the program. For example, if the expression is a function call, the call will be made.
VERIFY evaluates the expression but does not print or interrupt the program.
If it doesnt not interrupt the Program why do you need it ?
|
|
|
|
|
act_x wrote:
If it doesnt not interrupt the Program why do you need it ?
You still want the code to execute and do something usefull in the Release version.
e.g VERIFY(CloseHandle(hHandle));
In DEBUG will assert if it fails to close the handle. In RELEASE you still want it to attempt to close the handle.
You could write it:
BOOL bOK = CloseHandle(hHandle));
ASSERT(bOK);
Ant.
I'm hard, yet soft.
I'm coloured, yet clear.
I'm fruity and sweet.
I'm jelly, what am I? Muse on it further, I shall return! - David Walliams (Little Britain)
|
|
|
|
|
The simple answer is that when developers put a statement into an ASSERT while they are building code in debug versions, that statement can either be something that is used just to check a result or something that should execute AND check the result. Since many developers have a style of putting "real" code in their ASSERT statements, they found out that in the release build, those statements disappeared, as the ASSERT statements were ignored.
Thus the utility of VERIFY. If you use an ASSERT and only use a statement that tests a condition, then you are alright in both debug and release versions. If you put "real" code into an ASSERT and expect it to always execute in both debug and release versions, then you should use VERIFY instead.
"You can say that again." -- Dept. of Redundancy Dept.
|
|
|
|
|
I am developing a Dialog based application, which contains 5 tabs. In one of the
tabs microsoft media player control (version 9) is embedded. Now I want to
associate my application with media files, so that the media file double clicked is
played by the media player control embedded in one of the tabs. How can I achive it.
Please help..
Thanks in Advance.
|
|
|
|
|
|
Hello.
When I try to register my windows class using RegisterClassEx in my program I get an error which GetLastError tells me is error 120.
This apparently is:
This function is not supported on this system.
I find this confusing as an identical call in one of the programs in the SDK samples works fine? The only difference between the two is that my project is built using UNICODE. Could this affect the outcome of function calls with identical input?
This is the code:
LRESULT WINAPI MsgProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
case WM_DESTROY:
PostQuitMessage(0);
return 0;
case WM_PAINT:
case WM_TIMER:
case WM_GRAPHNOTIFY:
case WM_LBUTTONDOWN:
case WM_NEXTSCREEN:
case WM_STARTSCREEN:
HandleEvent(msg, wParam, lParam);
break;
case WM_DISPLAYCHANGE:
break;
case WM_CHAR:
{
if(wParam == VK_ESCAPE)
{
PostMessage(hWnd, WM_CLOSE, 0, 0);
}
else
{
PostMessage(hWnd, WM_NEXTSCREEN, 0, 0);
}
}
break;
}
return DefWindowProc(hWnd, msg, wParam, lParam);
}
HRESULT MakeWindow(HINSTANCE hInstance)
{
WNDCLASSEX wc = {sizeof(WNDCLASSEX),
CS_CLASSDC,
MsgProc,
0L,
GetModuleHandle(NULL),
NULL,
NULL,
NULL,
NULL,
L"Star Chart",
NULL};
RegisterClassEx(&wc);
}
... rest of windows code ...
How can it be that this identical code works fine in one project and not in the other?
Any ideas would be greatly appreciated because I have been at this for 6 hours now with no success...
If anybody needs to see any other code I would be glad to post it for you, I really just don't know what to try now...
edit:
I have now found that it is the GetModuleHandle() call that is producing the error? Can this be right?
Thanks in advance.
Mark Coleman
|
|
|
|
|
I think I managed to fix the problem, it was to do with the UNICODE preprocessor assignments. I don't think the functions like these assignments on 98.
Mark Coleman
|
|
|
|
|
Hi All
I want to implement hook to trap console windows messages.
say for example ...
one console application is runing .and one my application is runing.
both are totally independent application.
what i want is if console application minized or maximized or moved , my application should flag a message.
see if any one can help me with code.
Thanx
Rdgs
Efan
|
|
|
|
|
I am using MAPISendMail to open the compose mail window of my default mail client. Everthing is working fine except when i use MS Outlook 2000 as my default mail client the new message window which is opened through my application cannot be minimized and also i cannot start my MS Outlook when the new mail message window is open. Can anyone provide a solution to it.
-- Subu --
|
|
|
|
|
hi all ,
I want to convert CString Object to BYTE Object.How do I do that?.
My CString Object and pointer BYTE Object is given below.
BYTE * sampleFeatures;
CString s1;
thanks in advance
|
|
|
|
|
Type Casting will help
CString s1="codeproject";<br />
BYTE *p=(BYTE*)(LPSTR)(LPCTSTR)s1;
-----------------------------
"I Think this Will Help"
-----------------------------
Alok Gupta
visit me at http://www.thisisalok.tk
|
|
|
|
|
Hi There
Does anyone know the struture of Outlook's .MSG file? I would like to extract the actual email data/attachment from the file.
Any ideas/pointers?
Thanks
|
|
|
|
|
An Outlook MSG is just a text file with source code of your mail.
Take a look at Mail Propierties - Details - Source (with Express).
If you know a little SMTP, you understand this code.
Cheers!
JM
|
|
|
|
|
Is it possible to drop a dragged item between two nodes? That means the user should be able to "insert" a dragged item in the tree.
I've found nothing on this site yet
|
|
|
|
|
Hi Stevy,
Have u find answer for this question?. I'm also having the same issue can u please help me.
|
|
|
|
|
I have two dialog: one parent and one child.
Can I get the name (or the class) of the parent from the child?
thanks a lot
|
|
|
|
|
Really I don't Understand what do you want.
if You need to access the class member of parent from
child.
here is solution
In Child Dlg Class ,declare a var which is pointer to
Parent Class.
like this
CParentDlg *m_ParentDlg;
and Function
GetParentWnd(CParentDlg *m_Wnd)<br />
{<br />
m_ParentDlg=m_Wnd;<br />
}
now in Parent Class before calling the Child DLg
pass parent pointer
mChildDlg.GetParentWnd(this);
///call the domodal or showindow
and use m_ParentDlg in your Child class to access info from main parent Dlg
-----------------------------
"I Think this Will Help"
-----------------------------
Alok Gupta
visit me at http://www.thisisalok.tk
|
|
|
|
|
Thanks a lot for your answer but i can't use this solution.
I try to explain me better (i don't speak english very well).
I call the same child dialog from two different parent and i need to know wich is the parent in both the cases. Do you understand what i want?
Thanks a lot on more time!
|
|
|
|
|
Well, you could always send a registered message to your parent window and it can respond with a different return value depending upon which one it is.
Or, you can set a global variable containing the parent window's 'type when the parent is created and then the child can read it.
Or you can use GetParent and then call RealGetWindowClass.
There are other ways, but these came to mind pretty quickly.
|
|
|
|
|
CString str;
GetParent()->GetWindowText(str);
TOXCCT >>> GEII power
[VisualCalc] | [toxcct]
|
|
|
|
|
|
There are two threads:
//thread_one:
{
HANDLE hEvent=CreateEvent(NULL,TRUE,FALSE,NULL);
SetEvent(hEvent);
// do sth
// ...
AfxBeginThread(thread_two,this);
WaitForSingleObject(hEvent,INFINITE);
// continue to do sth...
}
thread_two:
{
ResetEvent(hEvent);
// do sth
// ...
SetEvent(hEvent);
}
I want thread_one to wait at WaitForSingleObject until thread_two passing SetEvent.
But the fact is thread_one wait at WaitForSingleObject for ever!!
|
|
|
|
|
After CreateEvent the only place you need to do anything with the event is at the end of thread_two. Remove the SetEvent in thread_one and ResetEvent in thread_two. Also make sure that the SetEvent in thread_two really sets the event that the WaitForSingleObject is waiting for. Mind local variable scope. I.e. if you have and event handle in your class called hEvent, and you do:
HANDLE hEvent = ::CreateEvent(NULL, TRUE, FALSE, NULL);
the class (or object really) hEvent (having the same name as above) will not be set and the WaitForSingleObject will wait for a non-initialized event, thus holding execution indefinitely.
Hope this helps.
|
|
|
|
|
The reason I call ReSetEvent is that WaitForSingleObject at thread_one is not always waiting for when thread_two sets the event, so I set the event to nonsignaled state by using ReSetEvent to make sure thread_one should wait at WaitForSingleObject when thread_two is running.
What's wrong with the ReSetEvent function I called could cause 'waiting for ever' ?
BTW. Assume there is no variable scope problem.
Thanks
|
|
|
|
|
Theres no problem per se. But the first reason thread_one is not waiting is because of the SetEvent (after the CreateEvent method). This means that when you get to the WaitForSingleObject, it will just continue right on. So as I said, you should remove it.
The second reason is multithreading. When you start thread_two, don't assume that the ResetEvent in thread_two will get executed before you get to the WaitForSingleObject in thread_one (it is less probable than not that that will ever happen). So this is why thread_one does not wait sometimes, all at the mercy of Windows thread scheduling.
So, remove the SetEvent in thread_one and the ResetEvent in thread_two (optionally of course, because it doesn't do anything) and the code as it stands should work A OK.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
