As I have stated in my question the OLE interfaace only works SF_RTF my text was streamed in SF_TEXT
I have decided to copy Visual Studio the code is probably in SF_TEXT if you look around the code there is a frame possibly a dialogbox frame the breakpoint is probably and CDC::Ellipse. bitmaps seem to have a 3d look With SF_TEXT you cann't draw in the rich edit it messes up the text. I drew on side of the adjoining dialogbox box frame what I really needed was the y coordinates got the from PosFromChar the x I can determine from the width of the dialogbox frame thank you
I posted this yesterday by mistake in the CLI forum, so I am reposting here. I am getting a heap corruption in my stream in function. I have a global variable, which keep count of the number of records I stream in the exception happens when the record count is 0x197e
When I insert the following code
if (nummachine == 0x000000000000196E)
and step thru the code everythibg works fine
the amount of characters i am streaming (as I said I am able to complete the process with the above code
is 0x7604d0 or 7,734480 decimal
I use the following code
though the function says that is intended for RTF code
here is the stack frame when I get the exception any debugging ideas would be much appreciated.
riched20.dll!CTxtPtr::InsertRange(long,unsigned short const *) Unknown
riched20.dll!CRchTxtPtr::ReplaceRange(long,long,unsigned short const *,class IUndoBuilder *,long,long *,unsigned long) Unknown
riched20.dll!CTxtRange::ReplaceRange(long,unsigned short const *,class IUndoBuilder *,enum SELRR,long *,unsigned long) Unknown
riched20.dll!CTxtRange::CheckLimitReplaceRange(long,unsigned short const *,int,class IUndoBuilder *,unsigned long,long *,long,int,unsigned long) Unknown
riched20.dll!CTxtRange::CleanseAndReplaceRange(long,unsigned short const *,int,class IUndoBuilder *,unsigned short *,long *,unsigned long) Unknown
riched20.dll!CLightDTEngine::ReadPlainText(class CTxtRange *,struct _editstream *,int,class IUndoBuilder *,long) Unknown
riched20.dll!CLightDTEngine::LoadFromEs(class CTxtRange *,long,struct _editstream *,int,class IUndoBuilder *) Unknown
riched20.dll!CTxtEdit::TxSendMessage(unsigned int,unsigned __int64,__int64,__int64 *) Unknown
user32.dll!CallWindowProcAorW(__int64 ,struct HWND__ *,enum _WM_VALUE,unsigned __int64,__int64,int) Unknown
mfc140d.dll!CWnd::DefWindowProcA(unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 1100 C++
mfc140d.dll!CWnd::WindowProc(unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 2100 C++
mfc140d.dll!AfxCallWndProc(CWnd * pWnd, HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 265 C++
mfc140d.dll!AfxWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 418 C++
mfc140d.dll!AfxWndProcBase(HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 299 C++
user32.dll!SendMessageInternal(struct HWND__ *,unsigned int,unsigned __int64,__int64,int) Unknown
> mfc140d.dll!CRichEditCtrl::StreamIn(int nFormat, _editstream & es) Line 775 C++
DriveRichEdit.exe!CProgDebug::OnInitDialog() Line 137 C++
DriveRichEdit.exe!CMainFrame::PROGDEBUG() Line 48 C++
DriveRichEdit.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * lpCmdLine, int nCmdShow) Line 26 C++
Yep that is how memory (heap) corruption works. You broke the heap at that point. Then somewhere after it something went to use the heap and at that point the data was bad.
Additionally the behavior that happens could be almost anything. Depends on what the actual data (bad) was in the heap and what it was attempting to do with it at that point, and even what was calling it.
Go back to the manufacturers and ask them: they are the only people with the source code, so they are the only ones who can help you fix it.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
That is usually a subjective thing. In general it should not be required.
But what happens, over time, is that as complexity grows so does the definitions.
And there are only two choices
1. Include the actual source of the definition
2. Include a short cut.
The first solution, in general requires that the compiler reread (parse, tokenize, etc) the full included source files every time and then likely the includes for those as well and that can continue for a while. That takes time. Compilers, now, tend to attempt to optimize that by using various caching strategies. But, at least in the past, some of those were less than reliable.
So people might want to avoid that by using short cuts. Thus the compiler can do far less work. And that is what that is.
Ideally of course the design should minimize all of that. Even at times to the point of perhaps reducing clarity. One trick that I used to use was to create two includes. One that was only for public consumption and the other for internal consumption (for example internal structs) and then the public visible items used something like a 'void *' and then I used casts for the internals. That did allow the external include to be smaller it size but it was a solution that only worked in some cases.
even with the comment "things grow in complexity "....
Have you worked with legacy systems? Systems that have been in continued use for 20 years with ongoing changes throughout that time period?
And for a product that has started with a small customer base but which has grown to many?
Google for example...
"span a whopping 2 billion lines of code that stretch across 1 billion files and require 86 terabytes of storage,"
Don't you suppose there are some less than ideal code in that?
Or if you prefer GCC is roughly 15 million lines of code.
Member 14968771 wrote:
and that should be all ( objective) what is needed
That is of course specifically subjective.
And you will not find any non-trivial application code base in C++ where the vast majority of files follow that model. Most will have many include files. Sometimes there are even include files that are nothing but a container for other include files (and that can recurse.)
I resolved all the initial heap errors still receiving some but I think I know the cause the Assembler listing I am streaming is 153 pages with 54 lines to page and about 130 characters across so that's a little bit over a meg large, Can I use LimitText to give myself the space?
I am working at blitting to back frame buffers a changing variety of bitmaps to create animations. When completed, that would be sent to the screen. I want to do this with minimum processing and minimum RAM.