CEdit SetPasswordChar SetFont [modified]
-
Hello, i've a problem with a subclassed CEdit on WindowsCE 5.0. If i use SetPasswordChar and SetFont in the same subclassed CEdit it generates an acces violation [Stack fault]: Thread=9a431400 Proc=98328d20 'xxxxxx.exe' AKY=00004001 PC=0017ba6c(xxxxxx.exe+0x0016ba6c) RA=000318e8(xxxxxx.exe+0x000218e8) BVA=1e2a1ee4 FSR=00000007 my Code: ... if(edit->SubclassDlgItem(IDC_EDIT1, this)){ edit->SetFont(m_Font, FALSE); edit->SetPasswordChar(0x25CF); // --> stack fault } ... If i don't use SetFont OR SetPasswordChar it works fine... whats wrong ??? can anybody help me? Thanx for replys... edit: // Initialization Controls.edit2 = new CMyEdit(); Controls.edit2->__SubClassControl(this, IDC_EDIT2); Controls.edit2->__SetMaxTextLength(9); //Controls.edit2->SetPasswordChar('*'); // --> stack fault Controls.edit2->SetPasswordChar(0x25CF); // --> stack fault // Control-Code BOOL CMyEdit::__SubClassControl(CMyDialog *pParent, int nID) { // subclassing per SubclassDlgItem is okay, SubclassWindow does not work m_pParent = pParent; m_nID = nID; BOOL ret = SubclassDlgItem(m_nID, m_pParent); // changing FontSize to parentfont and the heigth of the Control LOGFONT lf; if(m_pParent->GetFont()->GetLogFont(&lf) != 0){ // m_Font is a derived class from CFont and an Item of my CMyEdit for better Fonthandling // if i use CFont the same Problem exist with SetPasswordChar (isn't the reason) m_Font->_SetLogFont(lf); if(m_bFontResizing == TRUE){ CRect rect; GetClientRect(&rect); rect.DeflateRect(2,2,2,2); m_Font->_SetHeight(rect.Height()); } SetFont((CFont*)m_Font, FALSE); } return ret; } void CMyEdit::__SetMaxTextLength(int maxLen) { m_maxLen = maxLen; // del mask m_Mask = _T(""); }
modified on Friday, January 23, 2009 7:14 AM
If your edit control is set to multiline, that could be the problem. MSDN states that SetPasswordChar is not supported on multi-line edit controls.
Karl - WK5M PP-ASEL-IA (N43CS) PGP Key: 0xDB02E193 PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193
-
Hello, i've a problem with a subclassed CEdit on WindowsCE 5.0. If i use SetPasswordChar and SetFont in the same subclassed CEdit it generates an acces violation [Stack fault]: Thread=9a431400 Proc=98328d20 'xxxxxx.exe' AKY=00004001 PC=0017ba6c(xxxxxx.exe+0x0016ba6c) RA=000318e8(xxxxxx.exe+0x000218e8) BVA=1e2a1ee4 FSR=00000007 my Code: ... if(edit->SubclassDlgItem(IDC_EDIT1, this)){ edit->SetFont(m_Font, FALSE); edit->SetPasswordChar(0x25CF); // --> stack fault } ... If i don't use SetFont OR SetPasswordChar it works fine... whats wrong ??? can anybody help me? Thanx for replys... edit: // Initialization Controls.edit2 = new CMyEdit(); Controls.edit2->__SubClassControl(this, IDC_EDIT2); Controls.edit2->__SetMaxTextLength(9); //Controls.edit2->SetPasswordChar('*'); // --> stack fault Controls.edit2->SetPasswordChar(0x25CF); // --> stack fault // Control-Code BOOL CMyEdit::__SubClassControl(CMyDialog *pParent, int nID) { // subclassing per SubclassDlgItem is okay, SubclassWindow does not work m_pParent = pParent; m_nID = nID; BOOL ret = SubclassDlgItem(m_nID, m_pParent); // changing FontSize to parentfont and the heigth of the Control LOGFONT lf; if(m_pParent->GetFont()->GetLogFont(&lf) != 0){ // m_Font is a derived class from CFont and an Item of my CMyEdit for better Fonthandling // if i use CFont the same Problem exist with SetPasswordChar (isn't the reason) m_Font->_SetLogFont(lf); if(m_bFontResizing == TRUE){ CRect rect; GetClientRect(&rect); rect.DeflateRect(2,2,2,2); m_Font->_SetHeight(rect.Height()); } SetFont((CFont*)m_Font, FALSE); } return ret; } void CMyEdit::__SetMaxTextLength(int maxLen) { m_maxLen = maxLen; // del mask m_Mask = _T(""); }
modified on Friday, January 23, 2009 7:14 AM
grandmasta1 wrote:
edit->SetPasswordChar(0x25CF); // --> stack fault
I'm not sure how Windows CE treats char. But try using some simple char like '*' first.
-
No real idea here but what happens if you change the order, use SetPasswordChar first and then use SetFont? Any change?
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > Life: great graphics, but the gameplay sux. <
-
If your edit control is set to multiline, that could be the problem. MSDN states that SetPasswordChar is not supported on multi-line edit controls.
Karl - WK5M PP-ASEL-IA (N43CS) PGP Key: 0xDB02E193 PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193
-
grandmasta1 wrote:
edit->SetPasswordChar(0x25CF); // --> stack fault
I'm not sure how Windows CE treats char. But try using some simple char like '*' first.
-
Hello, i've a problem with a subclassed CEdit on WindowsCE 5.0. If i use SetPasswordChar and SetFont in the same subclassed CEdit it generates an acces violation [Stack fault]: Thread=9a431400 Proc=98328d20 'xxxxxx.exe' AKY=00004001 PC=0017ba6c(xxxxxx.exe+0x0016ba6c) RA=000318e8(xxxxxx.exe+0x000218e8) BVA=1e2a1ee4 FSR=00000007 my Code: ... if(edit->SubclassDlgItem(IDC_EDIT1, this)){ edit->SetFont(m_Font, FALSE); edit->SetPasswordChar(0x25CF); // --> stack fault } ... If i don't use SetFont OR SetPasswordChar it works fine... whats wrong ??? can anybody help me? Thanx for replys... edit: // Initialization Controls.edit2 = new CMyEdit(); Controls.edit2->__SubClassControl(this, IDC_EDIT2); Controls.edit2->__SetMaxTextLength(9); //Controls.edit2->SetPasswordChar('*'); // --> stack fault Controls.edit2->SetPasswordChar(0x25CF); // --> stack fault // Control-Code BOOL CMyEdit::__SubClassControl(CMyDialog *pParent, int nID) { // subclassing per SubclassDlgItem is okay, SubclassWindow does not work m_pParent = pParent; m_nID = nID; BOOL ret = SubclassDlgItem(m_nID, m_pParent); // changing FontSize to parentfont and the heigth of the Control LOGFONT lf; if(m_pParent->GetFont()->GetLogFont(&lf) != 0){ // m_Font is a derived class from CFont and an Item of my CMyEdit for better Fonthandling // if i use CFont the same Problem exist with SetPasswordChar (isn't the reason) m_Font->_SetLogFont(lf); if(m_bFontResizing == TRUE){ CRect rect; GetClientRect(&rect); rect.DeflateRect(2,2,2,2); m_Font->_SetHeight(rect.Height()); } SetFont((CFont*)m_Font, FALSE); } return ret; } void CMyEdit::__SetMaxTextLength(int maxLen) { m_maxLen = maxLen; // del mask m_Mask = _T(""); }
modified on Friday, January 23, 2009 7:14 AM
grandmasta1 wrote:
If i don't use SetFont...it works fine...
Since the edit control is just going to show a
*anyway, why does it need a different font?"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
-
grandmasta1 wrote:
If i don't use SetFont...it works fine...
Since the edit control is just going to show a
*anyway, why does it need a different font?"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
-
i change the fontsize to fit in the control... e.g. from size 8 to 15 - and the oher edit controls have size 15 looks not so fine, if the passwordcontrol has only size 8 if i use '*' as default, the access violation occurs if i set a new font. if the flag ES_PASSWORD or a PassworChar is set and i try to set a new font the access violation is always generated... i have no idea...
-
i try it, but it has no effect... the message EM_SETPASSWORDCHAR raises the error, mfc is not the reason...
So let me get this clear:
edit.SetFont(somefont);
edit.SetPasswordChar(whatever); <- it crashes herecrashes and
edit.SetPasswordChar(whatever); <- it crashes here again, so SetFont never gets called
edit.SetFont(somefont);crashes too but
edit.SetPasswordChar(whatever); <- works ok, no SetFont around
works. That is very strange, i don't really see the great difference between the later two cases since SetFont never gets called at all in either case.
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > Life: great graphics, but the gameplay sux. <
-
So let me get this clear:
edit.SetFont(somefont);
edit.SetPasswordChar(whatever); <- it crashes herecrashes and
edit.SetPasswordChar(whatever); <- it crashes here again, so SetFont never gets called
edit.SetFont(somefont);crashes too but
edit.SetPasswordChar(whatever); <- works ok, no SetFont around
works. That is very strange, i don't really see the great difference between the later two cases since SetFont never gets called at all in either case.
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > Life: great graphics, but the gameplay sux. <
not directly... edit.SetFont(somefont); edit.SetPasswordChar(whatever); <- it crashes here edit.SetPasswordChar(whatever); edit.SetFont(somefont);<- it crashes here edit.SetPasswordChar(whatever); <- works ok, no SetFont around i check now if the subclassing is the reason... wait a moment...
-
not directly... edit.SetFont(somefont); edit.SetPasswordChar(whatever); <- it crashes here edit.SetPasswordChar(whatever); edit.SetFont(somefont);<- it crashes here edit.SetPasswordChar(whatever); <- works ok, no SetFont around i check now if the subclassing is the reason... wait a moment...
Ah, i see. Where do you perform all this? I mean, the subclassinc of the edit and the rest? I mean, in what method, at what event...?
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > Life: great graphics, but the gameplay sux. <
-
Ah, i see. Where do you perform all this? I mean, the subclassinc of the edit and the rest? I mean, in what method, at what event...?
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > Life: great graphics, but the gameplay sux. <
-
MSDN says the Function has on effect in multineedit... i test it... edit: tested, but no effect
Here's a quote from MSDN: Remarks When a password character is set, that character is displayed for each character the user types. This member function has no effect on a multiple-line edit control. When the SetPasswordChar member function is called, CEdit will redraw all visible characters using the character specified by ch. If the edit control is created with the ES_PASSWORD style, the default password character is set to an asterisk (*). This style is removed if SetPasswordChar is called with ch set to 0. For more information, see EM_SETPASSWORDCHAR in the Platform SDK.
Karl - WK5M PP-ASEL-IA (N43CS) PGP Key: 0xDB02E193 PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193
-
grandmasta1 wrote:
edit->SetPasswordChar(0x25CF); // --> stack fault
I'm not sure how Windows CE treats char. But try using some simple char like '*' first.
Windows CE only supports Unicode. So all string MUST be L"" and all characters are 2 bytes.
«_Superman_»
-
Windows CE only supports Unicode. So all string MUST be L"" and all characters are 2 bytes.
«_Superman_»
i know... 0x25CF are 2 bytes, or not? ans strings with L"" or _T("") or TEXT("")... there is a single Character as parameter required in TCHAR-Format... the app works in emulator, it must be devicedependend... on an other device the app has no problem and works... thanx