Could it be because my project uses 1 byte (/Zp1) alignment?
When I run in debug, I get HEAP CORRUPTION DETECTED: after Normal block (#1779) at 0x0000020D8C33F570. CRT detected that the application wrote to memory after end of heap buffer. When I run in release, it doesn't crash but if I attach appverif.exe to my testheap2.exe, the heap corruption is caught. I am attaching my test project files
I just re-read your post and realized I forgot about the 2 overloaded constructors. The one works while guess the other doesn't. Thanks for submitting this bug.
Thanks for the continued assistance. as for the migration to the forum, I guess it is like the Borg: resistance is futile. The selection parameter didn't seem to matter. I looked at the source code as you suggested and was able to get some ideas. In my hello world project I made a constructor version of cf and the GetCharFormat version of cf. I printed all the elements of CHARFORMAT2 to separate files for each type of cf. I used BeyondCompare to look at the differences and eventually narrowed it...
I have been using OWLNext 7.1 until now when I tried to use the released 7.0.14. I have this global cf in my code owl::TCharFormat cf; //to fill cf I have this #if OWL_VERSION_16BIT >= 0x0701 cf = myrichedit->GetCharFormat(); #else myrichedit->GetCharFormat(cf); #endif #if OWL_VERSION_16BIT >= 0x0701 mylf = cf.GetFont(); #else cf.SetFontInfo(mylf); #endif #if OWL_VERSION_16BIT >= 0x0701 m_DefaultColor = cf.GetBkColor(); #else m_DefaultColor = cf.GetBkColor(); #endif mylf.lfHeight = 14; strcpy(mylf.lfFaceName,...
I use Notepad++ a lot but that is a new one for me. Thanks for posting that.