SetWindowText() causes access violation in release build

[Sahil]

ASSERTS doesn't work in release modes you might be recieving NULL in pEdit.
also try switching off the optimizations in release version

"Al" <anon...@discussions.microsoft.com> wrote in message
news:BE013515-F8A1-4ADB...@microsoft.com...
> I have a strange problem with my release build (it doesn't happen in the
debug build)
>
> I have a simple dialog and a wizard page, both of which access the same
data. So I have put the same controls with the same resource Id's on each
and I have a class which sets these controls on whichever dialog window it
is given. Whenever this class calls SetWindowText, I get an access violation
in the release build. Other dialog item related functions, such as
CComboBox::AddString() and CEdit::SetLimitText() work fine.
>
> Here's the code:
> CEdit *pEdit = (CEdit*)m_pDlg->GetDlgItem ( IDC_OPTION1 ) ;
> assert pEdit ;
> CString strText = pTsm->szOption1 ;
> pEdit->SetWindowText ( strText ); // <--- this goes Bang.
>
> The error I get is "Unhandled exception in MyApp.exe: 0xC0000005: Access
Violation.
>
> Any ideas?
>
> --- Al.
>
>

[Vishvesh Mushrif]

problem must in string. Try to debug ->

pEdit->SetWindowText ( strText );

ASSERT are put there so that that particular condition should not happen....
ever...

[Scott McPhillips [MVP]]

Al wrote:

> ----- HS wrote: -----
>
> If you use ON_CONTROL_RANGE the handler must take a parameter of type UINT.
>
> Thank you! Looking in MSDN has confirmed this. I obviously didn't research message map ranges thoroughly enough. Presumably I was just unlucky that in debug mode, the lack of this parameter didn't cause problems.
>
> Having said that, I still don't see how it did cause problems since I don't actually use it. Is it some aspect of the calling mechanism whereby it got put on the stack by the caller and my handler should have removed it on return but didn't because it thought there were no parameters?
>
> I've re-instated the message map range handler and it all seems to work. Many thanks.
>
> --- Al.
>

The caller passes the UINT by putting it on the stack. Your function is
declared wrong, so the compiler does not know the parameter was passed,
and so it pops the stack incorrectly when returning. This causes a
return to the wrong address, which begins executing garbage.

--
Scott McPhillips [VC++ MVP]

[Joseph M. Newcomer]

Several problems.

First, you should not even be considering GetDlgItem as a viable way to get access to a
control. Read my essay on Avoiding GetDlgItem on my MVP Tips site.

I presume that you are absolutely certain that IDC_OPTION1 is an edit control; if it isn't
that would explain a lot.

I don't know what
assert pEdit
means; it certainly isn't any C construct I recognize. And while there is an 'assert'
function in the C library, it is exceptionally poor style to actually USE it, because it
unfortunately exits the program, a Very Bad Thing to do. In MFC, you would write
ASSERT(pEdit != NULL);
which says what you want (writing code that pretends pointers are boolean variables is
something I consider an extremely sloppy form of coding)

Then for some obscure reason, you feel compelled to assign a member to a string variable
solely so you can use the string variable to pass as a parameter; there is no reason to do
this. You should just be able to write
c_Option1.SetWindowText(pTsm->szOption1);

Note that it takes exactly one simple line of code to do all of this, where you used four
overly complex lines for the same task.

When you get the access fault, the appropriate thing to do is enter the debugger and see
where it occurred. This will tell you if the problem was with the pEdit pointer or the
string. I don't see offhand, other than needlessly complex code to solve a trivial
problem, why this code would fail. But that's why we have debuggers.
joe

On Fri, 19 Mar 2004 02:36:09 -0800, "Al" <anon...@discussions.microsoft.com> wrote:

>I have a strange problem with my release build (it doesn't happen in the debug build)
>
>I have a simple dialog and a wizard page, both of which access the same data. So I have put the same controls with the same resource Id's on each and I have a class which sets these controls on whichever dialog window it is given. Whenever this class calls SetWindowText, I get an access violation in the release build. Other dialog item related functions, such as CComboBox::AddString() and CEdit::SetLimitText() work fine.
>
>Here's the code:
> CEdit *pEdit = (CEdit*)m_pDlg->GetDlgItem ( IDC_OPTION1 ) ;
> assert pEdit ;
> CString strText = pTsm->szOption1 ;
> pEdit->SetWindowText ( strText ); // <--- this goes Bang.
>
>The error I get is "Unhandled exception in MyApp.exe: 0xC0000005: Access Violation.
>
>Any ideas?
>
>--- Al.
>

Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm