If it won't crash for debug mode I'd take a look at any memory that you are
allocating (new) or arrays on the local stack. The debug mode moves things
mode. Since it's happening on the second time perhaps something in the
the second try. Of course, with memory problems, it's kind of like a time
Tom Serface wrote:
Does the size of the pasted text make any difference? Content?
Hi Tom, Ajay,
My wife has been beating this around. She seems to think it is when we
paste one of our constructed strings:
str {0x01240cc8
"{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\froman\fprq2 Times
New Roman;}{\f1\froman\fprq2\fcharset0 Times New Roman;}}{\colortbl
;}\viewkind4\uc1\pard\f0\fs24 \pard\tqr\tx4320\tqr\tx7200Year: 2003 Dollar
Amount: $21,600 Percent Increase: 3.00%\par
Year: 2014 Percent Increase: 3.30%\par
}"} ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> >
This is what it looks like just before a copy to the clipboard.
The brackets match, because of where I get the pieces I do have two
\pard's in a row. It may be that the above is just the right recipe to
crash the rich edit control.
I have a hard time as I can't get it to crash in debug. I had my wife sit
at my machine and work at it. Twenty minutes later, she called me over and
said she did it. That is where I got the info in the first post.
She also said she is sure that it won't crash on the first paste of one of
our strings but on the second.
We are going to ship today regardless, (I will take that double \pard
out). Nobody will ever duplicate the moves to get this crash. I hate
shipping with a known bug, I would never do it under any other
circumstance, but, tick, tick, tick...
Why this had to show up at the last minute, so the way life works. :)
Best, Dan.