ATL Edit field validation?
-
Hi All, I am writing an ATL/COM extension for a mapping application. All is fine except I am struggling to get field validation on Edit boxes to work. I open up a Modal ATL dialog and the user does there thing, but when it comes to the OnOk button event my code bombs when I try to get the text from the edit boxes
BSTR field1; BSTR field2; //this is ======> class CImportWizardDlg1 : public CAxDialogImpl this->GetDlgItemText(IDC_WIZEDIT1, field1); this->GetDlgItemText(IDC_WIZEDIT2, field2); EndDialog(wID);The error when I try the above is: Application Error- The instruction at "0x0f074b68" referenced memory at "0x0f074b68". The memory could not be "read" Which is not a very helpful message. In short, is there a an easy way to validate resources on an ATL dialog? thanks for your time in advance cheers Bryce -
Hi All, I am writing an ATL/COM extension for a mapping application. All is fine except I am struggling to get field validation on Edit boxes to work. I open up a Modal ATL dialog and the user does there thing, but when it comes to the OnOk button event my code bombs when I try to get the text from the edit boxes
BSTR field1; BSTR field2; //this is ======> class CImportWizardDlg1 : public CAxDialogImpl this->GetDlgItemText(IDC_WIZEDIT1, field1); this->GetDlgItemText(IDC_WIZEDIT2, field2); EndDialog(wID);The error when I try the above is: Application Error- The instruction at "0x0f074b68" referenced memory at "0x0f074b68". The memory could not be "read" Which is not a very helpful message. In short, is there a an easy way to validate resources on an ATL dialog? thanks for your time in advance cheers BryceAt the risk of stating the obvious, have you tried setting the BSTR variables to NULL first? It's eminently possible that it contains a garbage value. This causes the code to attempt to SysFreeString it first, and it's likely that is tripping the error. The eip looks about right for being somewhere in the system, rather than in "your" code. Steve S
-
At the risk of stating the obvious, have you tried setting the BSTR variables to NULL first? It's eminently possible that it contains a garbage value. This causes the code to attempt to SysFreeString it first, and it's likely that is tripping the error. The eip looks about right for being somewhere in the system, rather than in "your" code. Steve S
Hi Steve, Thanks for your help! You hit the nail on the head with your reply... exactly the problem. Will remember that one from now on. Another quick question if you can be bothered answering: Is it the programmers responsability to do the SysFreeString if they have called SysAllocString, or will be taken care of by the compiler? (Am relatively new to the ATL/COM system, and have had the luxury of the automatic garbage collection in java) Is there a general rule for COM objects for when they should be ->Release() or ->Detach(). It seems that if I call CoCreateInstance, then I need to call ->Release() otherwise if I have a smartpointer where I define it in a local scope, then I can only call ->Detach() or it is destroyed when scope is lost. Thanks once again cheers Bryce
-
At the risk of stating the obvious, have you tried setting the BSTR variables to NULL first? It's eminently possible that it contains a garbage value. This causes the code to attempt to SysFreeString it first, and it's likely that is tripping the error. The eip looks about right for being somewhere in the system, rather than in "your" code. Steve S
Hi Steve, Thanks for your help! You hit the nail on the head with your reply... exactly the problem. Will remember that one from now on. Another quick question if you can be bothered answering: Is it the programmers responsability to do the SysFreeString if they have called SysAllocString, or will be taken care of by the compiler? (Am relatively new to the ATL/COM system, and have had the luxury of the automatic garbage collection in java) Is there a general rule for COM objects for when they should be ->Release() or ->Detach(). It seems that if I call CoCreateInstance, then I need to call ->Release() otherwise if I have a smartpointer where I define it in a local scope, then I can only call ->Detach() or it is destroyed when scope is lost. Thanks once again cheers Bryce
-
Hi Steve, Thanks for your help! You hit the nail on the head with your reply... exactly the problem. Will remember that one from now on. Another quick question if you can be bothered answering: Is it the programmers responsability to do the SysFreeString if they have called SysAllocString, or will be taken care of by the compiler? (Am relatively new to the ATL/COM system, and have had the luxury of the automatic garbage collection in java) Is there a general rule for COM objects for when they should be ->Release() or ->Detach(). It seems that if I call CoCreateInstance, then I need to call ->Release() otherwise if I have a smartpointer where I define it in a local scope, then I can only call ->Detach() or it is destroyed when scope is lost. Thanks once again cheers Bryce
Depends. If you're writing a COM client (ie you're using objects and passing BSTR values in), the general rule is that if you allocate, you must free. There's a _bstr_t (and a CComBSTR) type that is like a smart-pointer for BSTRs but it's not perfect. If you have a smart-pointer to an interface, then it will call Release on destruct. Non-smart pointers don't, so you should. You wouldn't call Detach unless you needed a raw interface for some reason. Steve S