의 CEdit ::의 getline() 윈도우 7

I m_edit가의 CEdit 컨트롤입니다 다음 코드 세그먼트가 :의 CEdit ::의 getline() 윈도우 7

TCHAR lpsz[MAX_PATH+1]; 

// get the edit box text 
m_edit.GetLine(0,lpsz, MAX_PATH);

이 이전 Windows XP를 실행하는 컴퓨터에서 완벽하게 작동합니다. Vista에서는 이것을 테스트하지 않았지만 Windows 7에서는 lpsz에 정크 유니 코드 문자가 삽입되었습니다 (실제 텍스트는 물론 때로는). 여기에 무슨 일이 벌어지고 있는지에 대한 어떤 생각?

출처

2011-04-12 Eric Regnier

MFC를 사용하고 있으므로 CString 클래스를 사용하지 않는 이유는 무엇입니까? 이것은 많은 프로그래머가 MFC에 이끌린 이유 중 하나입니다. 문자열로 작업하는 것이 훨씬 쉬워지기 때문입니다.

예를 들어, 당신은 간단하게 작성할 수

int len = m_edit.LineLength(m_edit.LineIndex(0)); 
CString path; 
LPTSTR p = path.GetBuffer(len); 
m_edit.GetLine(0, p, len); 
path.ReleaseBuffer();

복사 된 라인은 널 종료 문자를 포함하지 않는 것을

주 (위의 코드는 윈도우 7에서 잘 작동하는 테스트) (documentation의 "비고"절 참조). 그러면 Windows의 이후 버전에서 볼 수있는 넌센스 문자를 설명 할 수 있습니다.

출처

2011-04-12 14:59:41

여기에 약간의 위험이 있습니다. 다른 스레드가 길이에 대한 쿼리와 실제 쿼리를 편집 컨트롤의 창 텍스트를 변경하여 줄을 가져올 수 있습니다. GetLine의 반환 값을 사용하여 방금 복사 한 텍스트 버전의 실제 길이를 유지해야합니다. (틀림없이 이것은 대부분의 GUI 코드에서 매우 드뭅니다.) –

@Adrian : 아마도 "매우 드문 것"대신에 단순히 "버그"라고 말하고 싶습니다. 이 경우 앱이 실패하기를 원하므로 별도의 스레드에서 실수로 UI 컨트롤에 액세스하고 있음을 알 수 있습니다. –

디자인에 컨트롤이 특정 스레드에서만 액세스되어야한다고 표시되면 예, 버그 일 수 있습니다. 모든 GUI 코드가 그런 식으로 설계된 것은 아닙니다. GetWindowText (CEdit :: GetLine 밑에 있음)는 다른 스레드 또는 다른 프로세스에서 텍스트를 가져 오는 작업을 처리하도록 특별히 설계되었습니다. –

null로 종료되지 않았습니다. 다음을 수행해야합니다.

int count = m_edit.GetLine(0, lpsz, MAX_PATH); 
lpsz[count] = 0;

출처

2011-05-18 21:37:18

의 CEdit ::의 getline() 윈도우 7

답변

관련 문제