|
Tomasz Sowinski wrote:
Why did you use your own 'main'?
It has to work as a console application in windows and unix besides gui.
-Janetta
|
|
|
|
|
But you've copied the AfxWinMain into your main, including the calls to AfxWinTerm?
Tomasz Sowinski -- http://www.shooltz.com
Never argue with an idiot, he'll bring you to his level and beat you with experience.
|
|
|
|
|
Tomasz Sowinski wrote:
But you've copied the AfxWinMain into your main, including the calls to AfxWinTerm?
No. I call AfxWinInit, InitApplication, InitInstance and Run myself. In AfxWinMain InitInstance and Run are called to a CWinThread, but I call those of the application. Could this be the problem? I tried adding AfxWinTerm after Run, but it didn't help.
-Janetta
|
|
|
|
|
Janetta wrote:
call those of the application. Could this be the problem?
I don't think so, but you may try to copy AfxWinMain into your main.
Tomasz Sowinski -- http://www.shooltz.com
Never argue with an idiot, he'll bring you to his level and beat you with experience.
|
|
|
|
|
Tried already, didn't help. Thank you anyway!
Anyone got any other ideas? Can I rely on CStrings being safe and not leaking memory themselves?
-Janetta
|
|
|
|
|
The CString data should delete itself when the ref count goes to zero. Which CString instance leaks? Do you do any CString::LockBuffer/CString::GetBuffer calls without matching CString::UnlockBuffer/CString::ReleaseBuffer?
Another possibility is that it doesn't really leak, I've seen people here at CP complaining that their leak detector was wrong (was it BoundChecker? Purify? I can't remember, doesn't use one myself), especially when dealing with global objects (such as the global CWinApp instance).
Cheers
Steen.
"To claim that computer games influence children is ridiculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
|
|
|
|
|
Steen Krogsgaard wrote:
Do you do any CString::LockBuffer/CString::GetBuffer calls without matching CString::UnlockBuffer/CString::ReleaseBuffer?
If I remember right, the things you mentioned should be ok. I can't get to the code right now, but I'll check when I can.
Thanks!
-Janetta
|
|
|
|
|
I want to use the RETURN and ESCAPE key in a control which I have placed on a dialog. I simply want to remove the RETURN and ESCAPE action (Ok/Cancel) from the dialog.
|
|
|
|
|
BOOL CMyDlg::PreTranslateMessage(MSG* pMsg)
{
if( pMsg->message == WM_KEYDOWN )
{
if( pMsg->wParam == VK_RETURN || pMsg->wParam == VK_ESCAPE )
{
::TranslateMessage(pMsg);
::DispatchMessage(pMsg);
return TRUE;
}
}
return CDialog::PreTranslateMessage(pMsg);
}
|
|
|
|
|
IMHO using PreTranslateMessage() for this is a bad idea. Your code snippet will disable the 'Enter' key from working on any and all button in the dialog. A person is far better off to override the OnOK() and OnCancel() functions and not call the base class implementations. The following code stops the 'Enter' key from closing the dialog unless the 'OK' or 'Cancel' button has the focus. It also stops the 'Escape' key from closing the dialog unless the 'Cancel' button has the focus. In all other instances, the keys work as would be expected.
void CMyDialog::OnOK()
{
if (GetFocus() == GetDlgItem(IDOK))
CDialog::OnOK();
}
void CMyDialog::OnCancel()
{
if (GetFocus() == GetDlgItem(ICANCEL))
CDialog::OnCancel();
}
CPUA 0x5041
Sonork 100.11743 Chicken Little
"So it can now be written in stone as a testament to humanities achievments "PJ did Pi at CP"." Colin Davies
Within you lies the power for good - Use it!
|
|
|
|
|
Hi,
I'm looking to catch an input error from a dialog box. I have edit boxes with doubles mapped to them so when letters are entered and the button is pressed the application automatically generates a MessageBox asking the user to enter a number. I want to catch this in order to be able to reset variables, etc. Is there a Message Handler for this?
Thanks,
Graham
|
|
|
|
|
gm_coll wrote:
I have edit boxes with doubles mapped to them so when letters are entered and the button is pressed the application automatically generates a MessageBox asking the user to enter a number
This is implemented in DDX_Text function. Calls to DDX_xxx functions are inserted in CYourDlg::DoDataExchange by ClassWizard. Unfortunately, there's no notification going back to your app when validation fails - MFC just displays a message box and throws CUserException, which is later catched in CWnd::UpdateData.
You basically have two options: catching CUserException (and throwing it again with argument-less 'throw') or doing data transfer/validation without DDX_ routines.
Tomasz Sowinski -- http://www.shooltz.com
Never argue with an idiot, he'll bring you to his level and beat you with experience.
|
|
|
|
|
Would I catch the CUserException in my BN_CLICKED message handler and carry out my additional functions before throwing the exception on?
Thanks in advance,
Graham
|
|
|
|
|
Data transfer/validation happens when UpdateData is called. MFC will call UpdateData for you in its OK handler. You may also call this method 'manually' in response to some event. Are you calling UpdateData yourself?
Tomasz Sowinski -- http://www.shooltz.com
Never argue with an idiot, he'll bring you to his level and beat you with experience.
|
|
|
|
|
I'm calling UpdateData() in my BN_CLICKED message handler to send the data from the controls to the variables. At the end of the function, after I have manipulated the variables, I call UpdateData(FALSE) to send the data back to the controls.
|
|
|
|
|
Your first call to UpdateData should be in try..catch block. Please note that MFC throws 'CUserException *'.
Tomasz Sowinski -- http://www.shooltz.com
Never argue with an idiot, he'll bring you to his level and beat you with experience.
|
|
|
|
|
Sorry - you need to provide try..catch in DoDataExchange. Otherwise CWnd::UpdateData will catch and process the exception.
Tomasz Sowinski -- http://www.shooltz.com
Never argue with an idiot, he'll bring you to his level and beat you with experience.
|
|
|
|
|
So within DoDataExchange I have to provide the code:
try
{
// code
}
catch (CUserException* e)
{
// carry out resetting of variables
}
Do I also have to throw the exception?
Thanks,
Graham
|
|
|
|
|
gm_coll wrote:
Do I also have to throw the exception?
Yes. Just use 'throw' without arguments, which transfers control to upper-level catch handler.
Tomasz Sowinski -- http://www.shooltz.com
Never argue with an idiot, he'll bring you to his level and beat you with experience.
|
|
|
|
|
Sorry, I'm still confused.
If I use a try..catch block in DoDataExchange what do I put in the try block, because what I am trying to do is transfer the data from the controls to the variables and this should already have happened. Will this not have already generated an exception when the data containing non-numeric characters is attempted to map to my double?
|
|
|
|
|
gm_coll wrote:
Will this not have already generated an exception when the data containing non-numeric characters is attempted to map to my double?
Yes, the exception was already generated and user has seen the MFC's message box. But you wanted to do something extra (at least this is what you originally posted). The catch block in DoDataExchange is your chance - you're getting control before DoDataExchange returns to CWnd::UpdateData.
Tomasz Sowinski -- http://www.shooltz.com
Never argue with an idiot, he'll bring you to his level and beat you with experience.
|
|
|
|
|
Hi,
I have a simple smart pointer implementation. Now, I want the pointer to allow type casting. For example, a derived class should be able to cast back to the base class etc. Any ideas on how to do this?
Here is the implementation so far:
template <class t="">
class SmartPtr
{
public:
/**
Default constructor.
*/
SmartPtr(): _p (0) {}
/**
Pass new directly as the argument
*/
SmartPtr (T* p): _p (p) {}
/**
Copy constructor
*/
SmartPtr(SmartPtr& source) :_p(source.Acquire())
{}
/**
Assignment operator: transfers ownership
*/
SmartPtr& operator= (SmartPtr& pSource)
{
if (_p != pSource._p)
{
delete _p;
_p = pSource.Acquire();
}
}
/**
Delete the pointer, when going out of scope.
The pointer does not get deleted if the owner has changed
*/
~XPtr () { delete _p; }
/**
Null out the pointer. So if the owner has changed and
this object goes out of scope, it does not delete the pointer.
*/
T* Acquire ()
{
T * pTmp = _p;
_p = 0;
return pTmp;
}
/**
for pointer like syntax
*/
T * operator->() { return _p; }
/**
Get the raw pointer
*/
T const & GetAccess () const { return *_p; }
private:
/**
The raw pointer
*/
T * _p;
};
Thanks,
Pankaj
Without struggle, there is no progress
|
|
|
|
|
Add 'operator T* () { return _p; }'
Tomasz Sowinski -- http://www.shooltz.com
Never argue with an idiot, he'll bring you to his level and beat you with experience.
|
|
|
|
|
Thanks! That worked! However, how is it that we do not have to supply any return type? Does C++ automatically determine the return type according to the casting operator. Also, I did not know that a class function could be without a return type. However, it works! So obviously I need to learn a lot! Any input on this will be greatly appreciated!
Pankaj
Without struggle, there is no progress
|
|
|
|
|
Without wishing to sound nasty or dificult or stupid...is this smart pointer implementation giving you anything more than auto_ptr in the Standard C++ Library - and if not, why not just use that?
Stuart Dootson
'Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p'
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
