Now let me expain my scenrio I am running a client server TCPI /IP program the server is a z/os mainframe and the client is a MFC C\C++ windows based program which displays data from the mainframe
I can have up to 4 modeless dialog boxes which display data in a rich edit their pointers live are my derived CWinApp
I did all the front end work created the accelarator in my resource file had it as selection in my menu "MENUITEM" and put the appropriate message map and message handler in derived CDialog CProgDebug
I then inserted the following code into my derived CWinAppp CDBGRApp
After I created the CProgDebug with it rich edit the window didnt seem to take any input mouse or keyboard
Nish in his code didnt specify that after doing TranslateAccelrator and would have to do TranslateMessage and DispatchMessage from the msg structure as I assume that is being taken care of somewhere down the line by the frameWork
The function returns nonzero when it successfully translates the accelerator, which is when you should not pass the message through to the default handler. Your code is bypassing the default handler entirely when your h_accel and debug variables are set (without checking if the message was a translated keycode).
thank you so much for your patience me However the way mine is set is INCORRECT as I dont have an IF testing for the validity of the TranlateAccelarator and that is why my keyboard gets locked becasue I havr return TRUE for all
I'm looking for a way to catch exceptions due to software or hardware errors and prevent my solution from breaking brutally, but I can't find anything complete.
I have read the two main ways of handling exceptions, C ++ and SEH, but it seems to me that both do not include all cases that can happen.
Can anyone help me ?
Greg Utas, thanks for article: i read it as soon as possible.
DevParty: ok, all cases is too much, but most of the cases?
I've tried both ways (exception C++ and SEH), but, for example, they catch division by zero, but not a string copy error.
In C/C++ you can copy a buffer to another, often a char array but not always, and unintentionally write past the end of the target. Less often but still possible you can write past the beginning as well.
So for example if you have a char and you write 6 bytes to that you have a problem.
The impact of this depends on where the buffer actually lives in the memory space and often what processing has been happening up to that point.