carriage return bug in Win32 edit controls?
-
I have a report (and a partial fix) from one of the guys who helps out on my VCF project, that when using EM_SETSEL/EM_GETSEL message, multiple lines broken by \r\n do not get handled correctly. Apparently the \r characters are not taken into consideration and the selection is screwed up. Has anyone else run into this? Is there a simple solution to handling this? ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
-
I have a report (and a partial fix) from one of the guys who helps out on my VCF project, that when using EM_SETSEL/EM_GETSEL message, multiple lines broken by \r\n do not get handled correctly. Apparently the \r characters are not taken into consideration and the selection is screwed up. Has anyone else run into this? Is there a simple solution to handling this? ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
I met this problem, and my solution is that I assumed there is no \r in the string, when processing EM_GETSEL message, but if I need \r, I can get string by invoking CEdit::GetWindowText(CString).
-
I have a report (and a partial fix) from one of the guys who helps out on my VCF project, that when using EM_SETSEL/EM_GETSEL message, multiple lines broken by \r\n do not get handled correctly. Apparently the \r characters are not taken into consideration and the selection is screwed up. Has anyone else run into this? Is there a simple solution to handling this? ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
Jim Crafton wrote: ...multiple lines broken by \r\n do not get handled correctly. Apparently the \r characters are not taken into consideration and the selection is screwed up. Which means what exactly? I've not yet seen the
\r\npair cause unknown problems.