|
Hi,
I am basically a MFC newbie my background is MainFrame Assembler and I am begining to feel comfortable writting OO code
my next hurdle is execption processing I have read the documentation and MFC has its own abstract classes for exception handling
The way I am understanding it is as follows an exception is cought by a
catch paragraph.. depeding on the type e.g. for a memory exception I would have to have a derived class of CMemoryException e.g
class Mymemoryexception : public CMemoryException
and do catch (Mymemoryexception *)
If I want more information I would have to register a exception handler
my question is the following what is the scope of the exception handler
is it perthread meaning if the catch paragraph is executing whitin a thread then it
will catch all exceptions for the thread ??
is the scope per object ??
I guess I am hoping somebody can give a better expliantion then the documentation from
MSDN
thanks
|
|
|
|
|
A catch clause will cath the specified exception and any derived exception.
In practice, if you don't write library for others, you rarely have to throw your own exception (and even less to catch them).
Generally you don't have to use exception handler and you should not have too much throw or catch in your code as exception are typically used for things that should not occurs.
MSDN documentation (and Google) are more complete documentation. It is not easy to explain it in a paragraph or two.
MFC and Visual C++ exception handling have some difference with standard C++ exceptions. For example catch ... will catch Win32 exceptions, MFC exceptions are thrown by pointer and exception specification is not implemented.
Philippe Mori
|
|
|
|
|
Somebody will throw the ball and somebody should catch it. So you should know the possibility of piece of code that throws and should decide where to catch and what exactly to catch.
Say, if you place a try and catch block on the main() or Win main, and leave the catch block empty or look for a more generic CException, all the exception can be caught if it is not handled by the called functions. Which is bad in a big application with millions of code.
So define the try..catch to a narrow down piece of code, and catch the specific exception say filenotfound exception should caught from the piece of code that opens a file.
More Info: Exception Handling for C# Beginners[^]
|
|
|
|
|
would it work If I define multiple catchs each with a different exception type
thanks
|
|
|
|
|
Sure.
try
{
}
catch( CDBException dbException )
{
}
catch( CMemoryException memException )
{
}
catch( CResourceException resException )
{
}
catch(...)
{
}
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
Ok so howabout this to know what type of error I got in what object
class Myexception : public CException
{
public:
catchit();
}
Myexception::catchit()
{
catch( CDBException dbException )
{
ReportError(MB_OK,cdbexcpid..)
}
catch( CMemoryException memException )
{
}
catch( CResourceException resException )
{
}
catch(...)
ReportError(OK,typeofexcpid)
{
runtimeptr = GetRunTimeClass();
// report on type of error in what object
}
does this sound like doable idea
thanks
|
|
|
|
|
Adding to David's reply, if you have one exception derived (subclassed) from another one in the list, put the catch for the derived (more specific) exception first or you'll never get to it. For example, catch divide-by-zero before arithmetic-exception.
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
ForNow wrote: for a memory exception I would have to have a derived class of CMemoryException
e.g
class Mymemoryexception : public CMemoryException Deriving your own class is not a requirement.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
Hi,
I have an issue when using this function,
the scenario is like that:
thread 1 invokes and creates thread 2 which monitors some data, using pthread_create with PTHREAD_CANCEL_ENABLE and PTHREAD_CANCEL_DEFERRED, then when thread 1 finishes his job it cancels thread 2 using pthread_cancel and everything is working fine, but the problem is that it seems that the threads are dead but still connected to the main projcess.
I am usin QNX OS which is a BSD flavor, same as Unix,
process view:
37560404 1 ./omadm_client 10r JOIN 5
37560404 2 ./omadm_client 10r CONDVAR
37560404 3 ./omadm_client 10r CONDVAR
37560404 4 ./omadm_client 10r REPLY
37560404 5 ./omadm_client 10r REPLY
37560404 6 ./omadm_client 10r DEAD
37560404 7 ./omadm_client 10r DEAD
37560404 8 ./omadm_client 10r DEAD
37560404 9 ./omadm_client 10r DEAD
37560404 10 ./omadm_client 10r DEAD
is it ok? how can I detach them from my main proccess? I do not see the point of uisn pthread_join unless it needs to be invoked for the termination process..
Many thanks,
Yossi,
|
|
|
|
|
It has been a long time since I used QNX, however what follows applies to all kernels and operating systems AFAIK:
- cancelling a thread often is unreliable; in general you don't know what state the thread and its data is in when you issue the cancel command, so you could end up with inconsistent data, with locked resources, etc.
- the better approach is "cooperative termination", where the thread's code helps in the thread either keeping active or exiting regularly.
So what I prefer to do in a monitoring thread typically looks like this (pseudo-code):
while(!enough) {
do whatever is needed for monitoring
wait a while
}
and when the caller wants it to terminate, just have it set the global boolean "enough" to true, the monitoring thread will exit (although not immediately, but that most often is OK).
|
|
|
|
|
Hi,
Thanks for the answer,
it is a problem because this thread is monitoring a file which it waits (sleeps) on it till something changes, so if nothing changes we will still sleep on the IO forever,
I free the global resources of the thread so this is not my cuncern, but do you know how to detach the thread from the process?
Many thanks,
Yossi,
|
|
|
|
|
ytubis wrote: do you know how to detach the thread from the process?
Sorry, I don't recall. I'm sure you could find that easily in the doc though.
ytubis wrote: if nothing changes we will still sleep on the IO forever
I tend never to do that; when the OS supports it, I prefer giving a reasonable timeout to all system calls, and then implement my own loop around it (possibly with logging and other logistics).
|
|
|
|
|
hi
i have developed program using opencv with mfc and i can't get the coordinates (x,y) of image in the static box using mouse click. image opens in separate window. the code is as:
void on_mouse( int evt, int x, int y, int flags, void* param )
{
if (evt = CV_EVENT_LBUTTONDBLCLK)
{
CString Blue, Green;
Blue.Format(_T("%d"), x);
Green.Format(_T("%d"), y);
SetDlgItemText(m_hWnd, IDC_Blue, Blue);
SetDlgItemText(m_hWnd, IDC_Green, Green);
}
}
the handle
HWND m_hWnd; is defined at beginning where the header files are included (i might be doing it wrong since i'm not good at programming with handle). the mouse callback function is defined in a thread as
cvSetMouseCallback("box.png", on_mouse, 0);
any idea what is wrong with this code.
Regards
Jawad
|
|
|
|
|
You are not specifying exactly what the problem is, but I am going to guess that you look at the x and y values and determine that they are incorrect.
If that is the case, try calling ScreenToClient()[^] to convert the screen coordinates to client coordinates of your dialog. You have to pass in the m_hWnd of you dialog as the first parameter.
Soren Madsen
|
|
|
|
|
sorry for not well explained
actually the problem is that static box does not show any value when mouse is being clicked. means it remains unchanged as it was.
Jawad
|
|
|
|
|
Oh, I see what you mean now.
You have a bug right there in your code. I am not sure if you get all mouse events in this handler (including mouse move events), but you should fix it and see if that solves your problem.
Change
if (evt = CV_EVENT_LBUTTONDBLCLK)
to
if (evt == CV_EVENT_LBUTTONDBLCLK)
Soren Madsen
|
|
|
|
|
SoMad wrote: ...but you should fix it and see if that solves your problem. True it should be fixed, but it won't make a difference as the expression (evt = CV_EVENT_LBUTTONDBLCLK) always evaluates to true.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
Yes, I had originally written that in my message, but took it out. At the time I was thinking there might be more code in this function that he had not included - like this could have been an "else if" with an "if" above it having a similar error. Otherwise this code would be called all the time since the handler processes all mouse events including mouse move.
I think the problem has to do with the window handle and I don't really like this call from a separate thread.
Soren Madsen
|
|
|
|
|
I just thought about something. You mention that the m_hWnd handle is defined, but do you actually assign it to the m_hWnd of your dialog object?
Soren Madsen
|
|
|
|
|
hi,
i'm still stuck with the dialog handle. i have posted the complete code. please i need help.
Regards
Jawad
|
|
|
|
|
jawadali477 wrote: the handle
HWND m_hWnd; is defined at beginning where the header files are included (i might be doing it wrong since i'm not good at programming with handle).
When do you define it? It has to be defined from the window handle AFTER it has been created (when using MFC, it means it should come after your window's OnInitDialog() has been called), otherwise it could be undefined.
FYI... your coding style seems more C-like than C++. Is your function global? Did you declare HWND m_hWnd a global variable? I hope you didn't do that because all MFC window based objects have a variable name m_hWnd.
|
|
|
|
|
hi,
i'm still stuck with the dialog handle. i have posted the complete code. please i need help.
Regards
Jawad
|
|
|
|
|
hi,
below is the complete code that i have developed. it builds fine and after debugging it shows two different windows, one containing image and other containing static boxes. but when i double click on the image window (which is my mouse event), values of (x,y) coordinates are not displayed in the static boxes (static boxes are in the separate window). please pardon my mistakes.
#include "stdafx.h"
#include "opencv01.h"
#include "opencv01Dlg.h"
#include "highgui.h"
#include "afxwin.h"
#include "cv.h"
#include "math.h"
#include<stdlib.h>
#ifdef _DEBUG
#define new DEBUG_NEW
#endif
void on_mouse( int evt, int x, int y, int flags, void* param );
HWND hwnd;
class CAboutDlg : public CDialog
{
public:
CAboutDlg();
enum { IDD = IDD_ABOUTBOX };
protected:
virtual void DoDataExchange(CDataExchange* pDX);
protected:
DECLARE_MESSAGE_MAP()
};
CAboutDlg::CAboutDlg() : CDialog(CAboutDlg::IDD)
{
}
void CAboutDlg::DoDataExchange(CDataExchange* pDX)
{
CDialog::DoDataExchange(pDX);
}
BEGIN_MESSAGE_MAP(CAboutDlg, CDialog)
END_MESSAGE_MAP()
Copencv01Dlg::Copencv01Dlg(CWnd* pParent )
: CDialog(Copencv01Dlg::IDD, pParent)
{
m_hIcon = AfxGetApp()->LoadIcon(IDR_MAINFRAME);
}
void Copencv01Dlg::DoDataExchange(CDataExchange* pDX)
{
CDialog::DoDataExchange(pDX);
}
BEGIN_MESSAGE_MAP(Copencv01Dlg, CDialog)
ON_WM_SYSCOMMAND()
ON_WM_PAINT()
ON_WM_QUERYDRAGICON()
END_MESSAGE_MAP()
BOOL Copencv01Dlg::OnInitDialog()
{
CDialog::OnInitDialog();
ASSERT((IDM_ABOUTBOX & 0xFFF0) == IDM_ABOUTBOX);
ASSERT(IDM_ABOUTBOX < 0xF000);
CMenu* pSysMenu = GetSystemMenu(FALSE);
if (pSysMenu != NULL)
{
CString strAboutMenu;
strAboutMenu.LoadString(IDS_ABOUTBOX);
if (!strAboutMenu.IsEmpty())
{
pSysMenu->AppendMenu(MF_SEPARATOR);
pSysMenu->AppendMenu(MF_STRING, IDM_ABOUTBOX, strAboutMenu);
}
}
SetIcon(m_hIcon, TRUE);
SetIcon(m_hIcon, FALSE);
AfxBeginThread(MyThreadProc, this);
return TRUE;
}
UINT Copencv01Dlg::MyThreadProc(LPVOID pParam)
{
Copencv01Dlg * me = (Copencv01Dlg *)pParam;
me->MyThreadProc();
return TRUE;
}
void Copencv01Dlg::MyThreadProc()
{
IplImage* img = cvLoadImage("box.png", CV_WINDOW_AUTOSIZE);
cvNamedWindow("map", 0);
cvShowImage("map", img);
cvSetMouseCallback("map", on_mouse, NULL);
cvWaitKey(0);
cvReleaseImage(&img);
cvDestroyWindow("map");
}
void Copencv01Dlg::OnSysCommand(UINT nID, LPARAM lParam)
{
if ((nID & 0xFFF0) == IDM_ABOUTBOX)
{
CAboutDlg dlgAbout;
dlgAbout.DoModal();
}
else
{
CDialog::OnSysCommand(nID, lParam);
}
}
void Copencv01Dlg::OnPaint()
{
if (IsIconic())
{
CPaintDC dc(this);
SendMessage(WM_ICONERASEBKGND, reinterpret_cast<WPARAM>(dc.GetSafeHdc()), 0);
int cxIcon = GetSystemMetrics(SM_CXICON);
int cyIcon = GetSystemMetrics(SM_CYICON);
CRect rect;
GetClientRect(&rect);
int x = (rect.Width() - cxIcon + 1) / 2;
int y = (rect.Height() - cyIcon + 1) / 2;
dc.DrawIcon(x, y, m_hIcon);
}
else
{
CDialog::OnPaint();
}
}
HCURSOR Copencv01Dlg::OnQueryDragIcon()
{
return static_cast<HCURSOR>(m_hIcon);
}
void on_mouse( int evt, int x, int y, int flags, void* param )
{
CString xaxis, yaxis;
if (evt == CV_EVENT_LBUTTONDBLCLK)
{
xaxis.Format(_T("%d"), x);
yaxis.Format(_T("%d"), y);
SetDlgItemText(hwnd, IDC_Blue, xaxis);
SetDlgItemText(hwnd, IDC_Green, yaxis);
}
}
Jawad
|
|
|
|
|
Hello
Env: Win7 64bits VS2010 Sp1Rel
When I maximized my MFC application, I'm unable to auto-unhide the taskbar. Sometimes, it flashes half a second and then stay hidden.
It's not a question of taskbar configuration. If I restore my app and maximize an other application (say Windows Explorer or Opera or any other ones ...), the taskbar auto-unhides correctly ...
Any clues why I got this strange behaviour ? Thanks for your Help
Thierry
|
|
|
|
|
I once had a problem like this when my application created a child window with the WS_POPUP style. It turns out that it should not have had that style set.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|