|
If I want to catch all the exception in the application?
|
|
|
|
|
You could put it in your main routine around all the calls to subroutines, but that is generally not a good idea. Much better to use it around specific areas where you know that an exception can occur, and you can then post specific information about it, or even attempt a recovery process.
Programming is work, it isn't finger painting. Luc Pattyn
|
|
|
|
|
I know that is a way.
But if need catch all the exception in the application how to do ?
|
|
|
|
|
yu-jian wrote: But if need catch all the exception in the application how to do ?
In the main function, however there still some exception or hazards which cannot be caught! review/find them on google!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
I already told you: in the main function, so it surrounds all other function calls.
Programming is work, it isn't finger painting. Luc Pattyn
|
|
|
|
|
All exception in application?
If you are worried about exception cause and details of it you should set up independent try catch blocks on the exception-likely part of the codes.
Mind you, not all part of the code blocks require a try-catch.
For example:
functionx()
{
int x = 0;
}
but this one needs
functionxy()
{
x = x/y;
}
And I usually prefer wrapping the exception blocks on the top most layers for ex:
Funct1()
{
try
{
funct2();
}
}
funct2()
{
}
But if care the least about exception details and want to have a global catch of the thrown ones,
Refer: Termnial Handlers on Windows.
|
|
|
|
|
|
I'm going to go contrary to Richard's advice here...
With a few exceptions (pardon the pun) exceptions in C++ should only be thrown when your code's going down in flames and there's no chance of recovery. This means that the only place you catch exceptions is around main. This means that your program dies cleanly after telling the user and programmer what's going on and releasing all its resources.
Having said that not everyone follows those rules. If you know a subsystem chucks exceptions out instead of error codes then write an exception eating wrapper around the subsystem and convert the exceptions to return codes.
Another place you have to use exceptions is around call backs into the OS. Don't let an exception fall into a OS hole or it may be fatal to the called app. This includes thread functions and window procedures.
Cheers,
Ash
|
|
|
|
|
I need to control the audio output of the left and right channel of speakers separately, I want to use one function to give the sound to Left channel and another for the right channel.
I am still new to programming, any help would be appreciated.
|
|
|
|
|
Read up on "mixer". That is MS common "device" for controlling variety of inputs , including audio.
Good luck.
Vaclav
|
|
|
|
|
How to change the background color of Edit control or combo box only when some one has edited the text of text box or change the slection of combo box?
Thanks in advance
asdasdadadasd
|
|
|
|
|
Background colors of controls are changed by handling the WM_CTLCOLOR message and returning a brush with the required color.
In your case, you also need to check the text in the control and only then return the brush.
You would also need to invalidate the control as soon as the edit text or combo selection is changed so that the WM_CTLCOLOR handler gets called.
|
|
|
|
|
hello guys... I am having a debug assertion when trying to use forward class declaration. Basically I have this CMyTabCtrl inwhich I have forward declared two dialog class, like this:
CMyTabCtrl.h
class CTabOneDlg;
class CTabTwoDlg;
And now in the implementaion file, I am using these pointers to create instances of two dialogs and add them to the TabCtrl.
Here are the constructor and the InitializeTabs() functions.
CMyTabCtrl.cpp
CMyTabCtrl::CMyTabCtrl()
{
m_arrTabs[0] = new CTabOneDlg;
m_arrTabs[1] = new CTabTwoDlg;
m_tabOne = (CTabOneDlg*)m_arrTabs[0];
m_tabTwo = (CTabTwoDlg*)m_arrTabs[1];
}
coid CMyTabCtrl::InitializeTabs()
{
this->InsertItem(0, _T("Faculty"));
this->InsertItem(1, _T("Admin"));
m_arrTabs[0]->Create(IDD_TAB1_DLG, this);
m_arrTabs[1]->Create(IDD_TAB2_DLG, this);
m_arrTabs[0]->ShowWindow(SW_SHOW);
m_arrTabs[1]->ShowWindow(SW_HIDE);
}
And finally when in MainDialogDlg.cpp, I try to forward declare this CMyTabCtrl class, it gives debug assertion on the second line of the InitializeTabs() function.
CMainDialogDlg.h
class CMyTabCtrl;
CMyTabCtrl *tabCtrl;
CMainDialogDlg.cpp
BOOL CMainDialogDlg::OnInitDialog()
{
tabCtrl = new CMyTabCtrl;
tabCtrl->InitizlizeTabs();
}
The debug assertion it gives is as follows
mfc100ud.dll!CTabCtrl::InsertItem(int nItem, const wchar_t * lpszItem) Line 570 + 0x2d bytes C++
Why it is giving debug assertion on the InsertItem() function in the InitializeTabs() function. Thanks for at least giving time to read it.
This world is going to explode due to international politics, SOON.
|
|
|
|
|
In which files have you #included the tab dialog and tab control headers?
|
|
|
|
|
Tab Dialog are #included in CMyTabCtrl.cpp like this
CMyTabCtrl.h
class CTabOneDlg;
class CTabTwoDlg;
CMyTabCtrl.cpp (Constructor)
m_arrTabs[0] = new CTabOneDlg;
m_arrTabs[1] = new CTabTwoDlg;
While the class for Tab control is #included in main dialog like this.
CMainDialogDlg.h
class CMyTabCtrl;
public:
CMyTabCtrl *tabCtrl;
CMainDialogDlg.cpp (OnInitDialog)
tabCtrl = new CMyTabCtrl;
tabCtrl->InitizlizeTabs();
BTW, this application works fine if I dont use forward decaration method and #include all the files, normally the way we do.
This world is going to explode due to international politics, SOON.
|
|
|
|
|
This has nothing to do with forward declaration; that is merely a convenience for the compiler. You should look more closely at the actual code, and use your debugger to step through and try to see which variable is causing the actual assertion.
Programming is work, it isn't finger painting. Luc Pattyn
|
|
|
|
|
Yes. I did exactly that. Everything works fine if I #include all the header files normally. The variable that acrually causing the problem is tabCtrl. It gives debug assertion in the second line of the InitializeTabs() function. The assertion it gives is as follows.
mfc100ud.dll!CTabCtrl::InsertItem(int nItem, const wchar_t * lpszItem) Line 570 + 0x2d bytes C++
And if you see the second line of the the said function then you will notice that it is merely inserting the tab dialog at the specified location like this
this->InsertItem(0, _T("Faculty"));
this->InsertItem(1, _T("Admin"));
So this should not be a problme I think.
This world is going to explode due to international politics, SOON.
|
|
|
|
|
Overloaded_Name wrote: It gives debug assertion
Yes, but what assertion; what is the value (or missing value) that actually causes the assertion?
Programming is work, it isn't finger painting. Luc Pattyn
|
|
|
|
|
It just takes me to this line in afxcmn.inl
{ ASSERT(::IsWindow(m_hWnd)); return CTabCtrl::InsertItem(TCIF_TEXT, nItem, lpszItem, 0, 0); }
If I see in the locals then I find these values
this 0x0019fc18 {CMyTabCtrl hWnd=0x00000000} CTabCtrl * const
nItem 0 int
If there is something else I should look for, then tell me.
This world is going to explode due to international politics, SOON.
|
|
|
|
|
That clearly shows that CMyTabCtrl has not been created properly, as it does not have a Window associated with it. You need to look at where you create it to try to discover why the create is failing, or why it has not been called properly.
Programming is work, it isn't finger painting. Luc Pattyn
|
|
|
|
|
Since the assertion indicates that the mhWnd is NULL, the problem lies in this area:
Overloaded_Name wrote: BOOL CMainDialogDlg::OnInitDialog()
{
tabCtrl = new CMyTabCtrl;
tabCtrl->InitizlizeTabs();
}
The first line creates an instance of the class, but does not create the window associated with it.
The second line tries to insert information into the window - but there is none.
As Richard MacCutchen said, you need to Create the tab control.
Hope this helps.
Karl - WK5M
PP-ASEL-IA (N43CS)
PGP Key: 0xDB02E193
PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193
|
|
|
|
|
Well spotted, I failed to notice this obvious mistake.
Programming is work, it isn't finger painting. Luc Pattyn
|
|
|
|
|
krmed wrote: The first line creates an instance of the class, but does not create the window associated with it.
Ok. I understand where the problem lies. But that's what I stated in my OP. If I do this application normally, like #including the tab files in the Tab Ctrl header file and then, #including this tab cntrl header file in the main dialog header file. And finally when I do
CMyTabCtrl tabCtrl;
tabCtrl.InitializeTabs();
It works perfectly. However thank you for your time. I am trying to do this, in this way as well.
This world is going to explode due to international politics, SOON.
|
|
|
|
|
Hi to all, I am subclassing an EDIT Control. But the WM_CREATE is not fired in Subclassed Procedure EditProc. What is wrong, i am unable to find. I had tried WM_NCCREATE also, but failed.
pls help..  
#include <Windows.h>
#include "resource.h"
WNDPROC OldEditProc;
HINSTANCE hInst;
HFONT hFont;
WNDPROC SUBCLASS(HWND hControl,WNDPROC newWindowProc)
{
return (WNDPROC)SetWindowLong(hControl,GWL_WNDPROC,(LONG)newWindowProc);
}
LRESULT CALLBACK EditProc(HWND hWnd,UINT Msg, WPARAM wParam, LPARAM lParam)
{
switch(Msg)
{
case WM_CREATE:
SetWindowText(hWnd,L"Welcome");
break;
}
return OldEditProc(hWnd,Msg,wParam,lParam);
}
LRESULT CALLBACK stdEditProc(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam)
{
switch(Msg)
{
case WM_INITDIALOG:
OldEditProc = SUBCLASS(GetDlgItem(hWnd,IDC_EDIT1),EditProc);
break;
case WM_CLOSE:
EndDialog(hWnd,TRUE);
break;
}
return FALSE;
}
INT APIENTRY wWinMain( __in HINSTANCE hInstance, __in_opt HINSTANCE hPrevInstance, __in_opt LPWSTR lpCmdLine, __in int nShowCmd )
{
hInst = hInstance;
return DialogBox(hInst,MAKEINTRESOURCE(IDD_DIALOG1),NULL,(DLGPROC)stdEditProc);
}
Regards,
Vishal
|
|
|
|
|
WM_CREATE and WM_NCCREATE will not be sent to the sub-classed procedure because they have already been sent to the original procedure. But you will get other WM_COMMAND messages and notifications.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
