Solved

Reading data from a big file to CRichEditCtrl is very slow!

Posted on 2002-06-03
66
1,678 Views
Last Modified: 2013-11-20
Hi,

I'm writing an application in which I am viewing files in a CRichEditView window. When I am trying to open big files and write them into the rich edit control using the CALLBACK function or even by SetWindowText it takes very long time.
In the callbck function I changed the read method to read huge but the pointer to the LPBYTE is small and also the cb which tells how many bytes to read is just 4094.
I guess that if I can change these values to be higher it will solve the problem or is there any other way to solve this problem?

Thanks,
Alon Shmuel
0
Comment
Question by:shmuelal
  • 32
  • 16
  • 9
  • +3
66 Comments
 
LVL 12

Expert Comment

by:migel
Comment Utility
Hi!
IMHO it is MS RichEdit control limitation so nothing you can do to accelerate this.
0
 
LVL 23

Expert Comment

by:Roshan Davis
Comment Utility
You can do this with the windows default MFC Wizard settings. Only the last dialog of the MFC Wizard, change the view to CRichEditView. Then MFC will do all the things for you. If you want call open explicitly use CDocuments OnOpenDocument with path.

GOOD LUCK
0
 

Author Comment

by:shmuelal
Comment Utility
So how they do it in the Visual Studio?
Can I write a CLLBACK function that overrides the one in the MSDN?
0
 

Author Comment

by:shmuelal
Comment Utility
Roshmon,
I know how to make an application with CRichEditView.
Pay attention to what I'm asking!
0
 
LVL 23

Expert Comment

by:Roshan Davis
Comment Utility
I meant that, If MFC gives some functionalities, they done in an optimum way.

I beg your pardon for commenting with an alternative.

Wish You All The Best

Roshmon
0
 
LVL 3

Expert Comment

by:GGRUNDY
Comment Utility
I suggest you try and use an
ITextDocument::Open call and see if there is any
speed improvement.

Something like (and this is a big ugly guess
'cause I haven't check this code).

#include <atlbase.h>
#include <tom.h>

BOOL LoadFile(CRichEditCtrl& edit, LPCTSTR pzFilename)
{
  CComVariant varName(pzFilename);
  CComPtr<IRichEditOle> pRichEditOle;
  pRichEditOle.Attach(edit.GetOleInterface());
  CComQIPtr<ITextDocument> pTextDocument(pRichEditOle);
  return SUCCEEDED(pTextDocument->Open(varName, tomOpenExisting, 0));
  }
0
 
LVL 32

Expert Comment

by:jhance
Comment Utility
>Pay attention to what I'm asking!

Now that's a great way to treat someone who is trying to help you.  Abusive users just aren't worth the effort...

I think I'll just leave you alone also.....
0
 

Author Comment

by:shmuelal
Comment Utility
GGRUNDY,

Can you please explain me your suggestion.
I see that you use a COM interface, is this is an object that I should add to the project in case I'm doing an installation program to my prorject?
0
 
LVL 3

Expert Comment

by:GGRUNDY
Comment Utility
>I see that you use a COM interface, is this is an object
>that I should add to the project in case I'm
>doing an installation program to my prorject?
No need to add anything. Just try the code I gave you.
All RichEdit controls have that COM interface hidden
deep within their dark heart.

good luck.
0
 

Author Comment

by:shmuelal
Comment Utility
GGRUNDY,

I inserted your code and I got these errors:
about the #include <tom.h> - no such file

When I removed this include I got this error:
GetOleInterface' : is not a member of 'CRichEditCtrl'

0
 

Author Comment

by:shmuelal
Comment Utility
Hi GGRUNDY

Well, I've successfuly compiled it, but it seems that it doesn't work.
The window is opened but with no content.
any idea?
0
 

Author Comment

by:shmuelal
Comment Utility
roshmon

I'm sorry if you were hurt from what I told you, I didn't mean to.
I appreciate your good will.
I would be glad if you could help me.
0
 
LVL 3

Expert Comment

by:GGRUNDY
Comment Utility
Hmmm

1) Check that the RTF file you are opening will open happily
in WORDPAD.

2) try replacing the last line with...

HRESULT hr = pTextDocument->Open(varName, tomOpenExisting|tomRTF, 0));
return SUCCEEDED(hr);

(Note the extra flag tomRTF)
 
3) let me know what the value of the "hr" result is.

4) Zip the project up and email to ggrundy@bigpond.com

Cheers
0
 

Author Comment

by:shmuelal
Comment Utility
GGRUNDY,

I tried what you offered, and it seems a little bit better, but still this is slow.
If you take a file of 100k or more it takes few seconds.
Also, I want to view *.s files that they are text files, and I gor hr result which says that he can't find the files.
0
 
LVL 3

Expert Comment

by:GGRUNDY
Comment Utility
If you open one of these 100k files in WordPad, how long does it take?

If WordPad can't open your document with the response times your require your only option will be to use some form of "Just in Time" demand loading of a roll-your-own text control, or maybe load your RichEdit control up in a lowpriority background thread, so that at least the user isn't stuck, waiting around.

PS
There is a tomText, a tomHTML & a tomWordDocument
flag which you can also use. But I understand if you
leave them out the interface will try to figure out
the correct format dynamically.
0
 

Author Comment

by:shmuelal
Comment Utility
You right.
But I look at the visual studio's speed.
How did they do it?
0
 
LVL 3

Expert Comment

by:GGRUNDY
Comment Utility
If you look at the visual studio view using Spy++ you will see that it isn't a RichEdit control.

It is probably, as I suggested, a roll-you-own edit window using a just-in-time loading technique.
0
 
LVL 49

Expert Comment

by:DanRollins
Comment Utility
If the file that you are reading is plain text (no RTF codes) then you can request SF_TEXT format in the StreamIn call.

Also, you can increase load speed as follows:

Read a large block of the file into RAM:  I tested by reading the entire 100K file into a buffer.  Then in your callback, you don't need to do individual 4K disk reads chunks as requested.  Instead, just transfer part of the 100K block.

In summary, do all of the file I/O at one time, then use high-speed memory block transfers in the callback.  After that you are limited by the speed at which the RichText control can process the incoming data -- which will be faster if you are processing regular text than if you are processing RTF.

I can provide code if you can't understand what I am suggesting.

-- Dan
0
 

Author Comment

by:shmuelal
Comment Utility
I would be very glad to see some code.
0
 

Author Comment

by:shmuelal
Comment Utility
I would be very glad to see some code.
0
 
LVL 49

Expert Comment

by:DanRollins
Comment Utility
On my clunky 500Mhz machine, this loads a 100KB file in the blink of an eye.  It loads a 1.5 MB (1500KB) file in a couple of seconds.



typedef struct {
     char* pBuf;
     int nCur;
     int nMax;
} MyReCallbackData;


static DWORD CALLBACK
MyStreamInCallback(DWORD dwCookie, LPBYTE pbBuff, LONG cb, LONG *pcb)
{
     MyReCallbackData* pr= (MyReCallbackData*)dwCookie;
     if ( pr->nCur >= pr->nMax ) {
          *pcb=  0;
          return(0);
     }
     *pcb=  cb; // assume normal block
     if ( pr->nCur + cb > pr->nMax ) { // else final partial block
          *pcb=  pr->nMax - pr->nCur;
     }
     memmove( pbBuff, pr->pBuf+pr->nCur, *pcb );
     pr->nCur += *pcb;

   return 0; // 0= success
}

void CMyDlg::OnButton1()
{
     MyReCallbackData rMRCD;
     EDITSTREAM       rES;
     CFile            cFile( "c:\\temp\\testfile.rtf", CFile::modeRead );

     //------------------------------ read entire file into buffer
     rMRCD.nMax= cFile.GetLength();
     rMRCD.nCur= 0;
     rMRCD.pBuf= new char[ rMRCD.nMax ];
     cFile.Read( rMRCD.pBuf, rMRCD.nMax );  

     // dox are wrong: must set or limits to 32k!
     m_ctlRichEdit.LimitText( rMRCD.nMax );

     rES.dwCookie=    (DWORD)&rMRCD;
     rES.pfnCallback= MyStreamInCallback;
     m_ctlRichEdit.StreamIn( SF_RTF, rES );
}

-- Dan
0
 

Author Comment

by:shmuelal
Comment Utility
Hi Dan,
First of all, thanks.
It is still as slow as it was.
The part of reading the data using the CALLBACK function is slow.
I see that the block size of reading are still 4K.
Maybe I miss something here?
0
 
LVL 49

Expert Comment

by:DanRollins
Comment Utility
Slow?  It loads 1.5MB file in under two seconds.

The 4K block is the amount of data that the control requests.  It is not possible to control the block size.  Also, it is irrelevant because the requests come very quickly.  My technique minimizes disk access overhead which will speed things up, but probably not a lot unless you have a really slow disk.

I think that perhaps you are running a very slow computer.  In that case, never fear because when your program runs on other computers it will run very quickly.

-- Dan
0
 
LVL 12

Expert Comment

by:migel
Comment Utility
Hi!
also speed of loading depends on document complexity.
0
 

Author Comment

by:shmuelal
Comment Utility
Migel - What do you mean "Document Complexity"?
It doesn't read the document in a "blind" way?

Dan - I don't know, but it is as slow as it was before.
I have a 550MHz CPU!!!
Also, I try to read a text file so I changed the code to be:
m_ctlRichEdit.StreamIn( SF_TEXT, rES );

It has any connection?
0
 
LVL 12

Expert Comment

by:migel
Comment Utility
Hi!
I mean - number of styles frames, pictures, ole objects, tables and so on...
RTF format (and similar formats too) required lot of work to transfer stream into the text on the screen.
0
 
LVL 49

Expert Comment

by:DanRollins
Comment Utility
With ST_TEXT the question of document complexity is moot -- the control does not need to perform any character-by-character processing.

shmuetal,
I don't suppose that you are using a non-English version or Windows or importing DBCS or UNICODE data are you?

Here are some other variables could affect RE performance:

* Version of RE control
* Other simultaneous processes hogging the CPU
* Network latency: Is the file on a local hard disk?
    Disk latency: Is the disk slow?
* RE Control settings: Are you using any oddball settings or callbacks or notif masks or anything?  My testing assumed ALL defaults:  I added an RE control to a dialog-based MFC app and then added just the code that I provided here (plus AfxInitRichEdit in InitInstance)

-- Dan
0
 
LVL 3

Expert Comment

by:GGRUNDY
Comment Utility
>also speed of loading depends on document complexity
Do you have any influence over the format in which the documents are stored in the first place?
If so, you will find that "Word for Window 6.0 is a slightly faster format.
(tomWordDocument)
0
 

Author Comment

by:shmuelal
Comment Utility
Hi DanRollins and GGRUNDY,

-My window also supports hebrew.
-The rich edit control I'm using is a CRichEditView in an MDI application. This is the view of my program.
-The file that I'm trying to read is local.
-Regarding simultaneous processes: well this is a workstaion ad I have the MSDN open and the Outlook and also the regular services running.
-The version of the RE control is what I got from the visual studio as I define this application to have a CRichEditView as a view.
-My disk is 5400 RPM, the older one - do you think that this is the reason?

I'm sorry to not answering you on Friday or Satursay, but we do not work in those days.
Thanks
0
 
LVL 49

Expert Comment

by:DanRollins
Comment Utility
You can determine if disk speed is a problem by using the pre-load to memory technique I showed above.  Breakpoint on the line:

   cFile.Read( rMRCD.pBuf, rMRCD.nMax );  

Single step across that line... that is how long it takes to load the file into memory.

Next, single step down to the line:

   m_ctlRichEdit.StreamIn( SF_RTF, rES );

and single-step across it... That is how long it takes for the RE control to process the data.

I have heard other users complain about RE being slow but never seen any evidence.  However, the hebrew support could easily throw a monkey wrench into the works. I think it will need to right-justify everything in the file... a VERY time-consuming task.  

Is there any way to turn off hebrew support in order to see if that is what's slowing things down?

-- Dan
0
 

Author Comment

by:shmuelal
Comment Utility
Well,

I checked the what you say and the time consumer is the:

"WorkingRTF.StreamIn(SF_RTF, rES);"

So it is not the disk!
It seems that the control is the problem.
Maybe if I take the rich edit v2 or v3 it will be better?

I don't think that the Hebrew is the problem, but maybe you right. I will try to find a way to disable it.

0
 

Author Comment

by:shmuelal
Comment Utility
I appreciate the time you invest, so I raised the points for this question.
0
 
LVL 12

Expert Comment

by:migel
Comment Utility
Hi!
can you show part your RTF file?
0
Why You Should Analyze Threat Actor TTPs

After years of analyzing threat actor behavior, it’s become clear that at any given time there are specific tactics, techniques, and procedures (TTPs) that are particularly prevalent. By analyzing and understanding these TTPs, you can dramatically enhance your security program.

 

Author Comment

by:shmuelal
Comment Utility
Hi migel,

I dont have any RTF file.
I just takes a text file or .cpp file and trying to view it in the control.
The 150k file I try to view is a text file and if you want I can send you it.
0
 
LVL 12

Expert Comment

by:migel
Comment Utility
Hi!
why you use SF_RTF flag to load just text (cpp) file?
0
 
LVL 49

Expert Comment

by:DanRollins
Comment Utility
If the file that you are reading is plain text (no RTF codes) then you can request SF_TEXT format in the StreamIn call.

-- Dan
0
 

Author Comment

by:shmuelal
Comment Utility
For the text file I use the SF_TEXT.
The cpp file is processed in a function I wrote and I color the text like in the Visual Studio Editor so it must be RTF.
0
 
LVL 12

Expert Comment

by:migel
Comment Utility
hi!
may be main problem in your processor?
0
 

Author Comment

by:shmuelal
Comment Utility
I have 550 Mhz.
You know what, I will check it on another computer!
0
 
LVL 12

Expert Comment

by:migel
Comment Utility
Hi!
hmm I mean that preprocessor of the cpp file may slow your loading
or you insert plan cpp file as RTF?
0
 
LVL 49

Expert Comment

by:DanRollins
Comment Utility
Do *other* RTF files  -- files that are not created by your colorizing program -- load slowly also?  

To test, open up WordPad and create some text.  Then highlight a few passages and make them bold.  Makes ome other stuff italic.  Now copy and paste until you have a 100KB file.  Save it and then try loading it in your program.

If the headers of the RTF are complicated (by defining many styles and fonts and so forth) the RTF processing will take much longer.

-- Dan

0
 

Author Comment

by:shmuelal
Comment Utility
Now I'm very confused!

I made an RTF file that was almost 300kb with italic, bold and what ever. It read it in maybe 1 second!
The problem is not only with the cpp file that I'm coloring, it is also in regulat text file.
I saw that the part of the insertion to the control is very slow.
0
 

Author Comment

by:shmuelal
Comment Utility
Now I'm very confused!

I made an RTF file that was almost 300kb with italic, bold and what ever. It read it in maybe 1 second!
The problem is not only with the cpp file that I'm coloring, it is also in regulat text file.
I saw that the part of the insertion to the control is very slow.
0
 

Author Comment

by:shmuelal
Comment Utility
I think I have a found something.
If I read from an RTF file, it pops up immedialtly no matter what's the size of the file.
When I open a CPP file and do what I do it takes more time.
For example I opened an RTF file that his size is 250 KB and it took right away.
Then, I opened a CPP file that his size is 40 KB and it took a bit more.
What do you say?
Should I convert my files into RTF files first?
0
 
LVL 12

Expert Comment

by:migel
Comment Utility
code for loading cpp file please :-)
0
 

Author Comment

by:shmuelal
Comment Utility
This is the code.
It is not diferenet from what you know.
If I put at the szSourceFile a string that is a path of an RTF file the part of running the callback function is very fast.

// Load source file text
if(!sourceFile.Open(szSourceFile, CFile::modeRead, &ex))
{    
//If fail to open file
#ifdef _DEBUG
     char szErrMsg[255];
     ex.GetErrorMessage(szErrMsg, 255);
     afxDump << "Fail to open file: " << szErrMsg << "\n";
#endif // _DEBUG
     return;
}
     
// Process code
tokenizer.SetLanguageInfo(pLI);
tokenizer.SetText(&szCode);
tokenizer.FindTokens();
     
     
// Export result
MyReCallbackData rMRCD;
EDITSTREAM       rES;

rMRCD.nMax= sourceFile.GetLength();
rMRCD.nCur= 0;
rMRCD.pBuf= new char[ rMRCD.nMax ];
sourceFile.Read( rMRCD.pBuf, rMRCD.nMax );  

// dox are wrong: must set or limits to 32k!
WorkingRTF.LimitText( rMRCD.nMax );

rES.dwCookie=    (DWORD)&rMRCD;
rES.pfnCallback= MyStreamInCallback;
WorkingRTF.StreamIn( SF_RTF, rES );
     
posBlock = tokenizer.GetBlocks()->GetHeadPosition();
cf.dwMask = CFM_COLOR;
while (posBlock != NULL)
{
    blockItem = tokenizer.GetBlocks()->GetNext(posBlock);
    switch (blockItem.blockType)
    {
     case Normal:
           cf.crTextColor = pLI->crNormalColour;
           break;
     case Comment:
           cf.crTextColor = pLI->crCommentColour;
           break;
        case String:
           cf.crTextColor = pLI->crStringColour;
           break;
     case Keyword:
           cf.crTextColor = pLI->crKeywordColour;
           break;
        case Operator:
           cf.crTextColor = pLI->crOperatorColour;
           break;
     default:
           cf.crTextColor = pLI->crNormalColour;
           break;
     }
         
     WorkingRTF.SetSel(blockItem.blockRange.nFrom,        blockItem.blockRange.nTo + 1);
     WorkingRTF.SetSelectionCharFormat(cf);
     WorkingRTF.SetSel(0,0);
}
     
delete [] rMRCD.pBuf;
WorkingRTF.UnlockWindowUpdate();
sourceFile.Close();
0
 
LVL 49

Expert Comment

by:DanRollins
Comment Utility
I just want to understand something...

Are you saying that regular RTF loads quickly?  Are you saying that the delay has been caused by some outside tokenizing process?

shmuelal,
The delay is in the tokenizer object and/or the code you execute after streaming in the text.

Why have you been wasting our time?

-- Dan
0
 

Author Comment

by:shmuelal
Comment Utility
Dan,

even if I put my tokenizer in comment, it has the same perfomance.
That's what I try to explain to you.
Try to take a large cpp file and try to use your code to load this file to the richedit control.
I'm sorry for wasting your time, but I'm sure there is a problem.
0
 
LVL 49

Expert Comment

by:DanRollins
Comment Utility
I think that the problem is that the RE Control is trying to parse that CPP file as an RTF file.  That eats up time.

Lets go back one step.  If you use:

   WorkingRTF.StreamIn(SF_TEXT, rES);

to read in the cpp file, does it go quickly?  If so, then use it.  Read a text file as text.

-- Dan
0
 

Author Comment

by:shmuelal
Comment Utility
OK,
there is an improvement.
but now I can't colorize the code.
0
 
LVL 12

Expert Comment

by:migel
Comment Utility
Hi!
so you have to convert cpp to rtf during loading stream into the control
0
 

Author Comment

by:shmuelal
Comment Utility
Ok,

Can I do the convertion from cpp file to rtf file in the memory and not to create an RTF file?
0
 
LVL 49

Expert Comment

by:DanRollins
Comment Utility
>>but now I can't colorize the code.

Whaat makes you think thaat?  I don't suppose that you took a few seconds to try, did you?  In this I read in a 150KB cpp file, and then colorized some code.

     CFile            cFile( "c:\\temp\\testfile.cpp", CFile::modeRead );
     ...
     m_ctlRichEdit.StreamIn( SF_TEXT, rES );

     m_ctlRichEdit.SetSel(20,50);
     CHARFORMAT rCF;
     rCF.dwMask=    CFM_STRIKEOUT|CFM_BOLD |CFM_COLOR;
     rCF.dwEffects= CFE_BOLD;
     rCF.crTextColor= RGB(255,0,0);
     m_ctlRichEdit.SetSelectionCharFormat( rCF );

-- Dan
0
 

Author Comment

by:shmuelal
Comment Utility
Well,

I think that this is it.
Give me few hours with this and if I don't have any problem I will accept your comments.
0
 

Author Comment

by:shmuelal
Comment Utility
If it is not bother for you, I have another request.
Can you try to load a .txt file with a sze of about 150 KB.
I tryed to read it with SF_TEXT and it takes long time.
I'm using the code you sent me and this is the only thing I do, which mean loading the file into the control.
It takes almost 10 seconds the part of the calling to the CALLBACK function.

Thanks
0
 
LVL 49

Expert Comment

by:DanRollins
Comment Utility
That is very strange.  I loaded in a 150KB text file (a cpp file) in well under one second, using rhe code that I previoulsy showed.  I was careful to use SF_TEXT in the StreamIn function call.  It was not a UNICODE file.  It contained no Hebrew letters.  It loaded instantly.

-- Dan
0
 

Author Comment

by:shmuelal
Comment Utility
It is very strange.
I checked it on another computer that is just with English and it was very fast.
What is going on here? you right, I think that it relates in a certain way to the Hebrew that installed in my computer.

It means that I have to find a solution to this problem too, because this application will be used on computer that also has Hebrew enabled and if it will be load like it is now I it wouldn't be good.
0
 
LVL 49

Expert Comment

by:DanRollins
Comment Utility
I do not have a Hebrew-capable computer for testing, so I must rely on your help in searching for a solution.

Maybe selecting a different default font before loading will make a difference.  Maybe setting a different default paragraph format before loading will make a difference.

Try this.  Before calling StreamIn(), call GetDefaultCharFormat().  Report here what is returned in the CHARFORMAT structure.  Also call GetParaFormat() and report here what is returned in the PARAFORMAT structure.

Try some experiments by calling SetDefaultCharFormat() with various settings before calling StreamIn().  Try some more experiments by calling SetParaFormat() with various settings before calling StreamIn().

-- Dan
0
 
LVL 49

Expert Comment

by:DanRollins
Comment Utility
Also, use Spy++ and report the style codes of the RE control. -- Dan
0
 

Author Comment

by:shmuelal
Comment Utility
First, thanks for your time.

The CHARFORMAT2:
cbSize = 0x0000003c
dwMask = 0xf800003f
dwEffects = 0x4000000
yHeight = 0x000000c8
yOffset = 0x00000000
crTextColor = 0x00000000
bCharSet = 0x00
bPitchAndFamily = 0x00
szFaceName = "Courier"
-From some reason the extra attributes that belong to the CHARFORMAT2 are with junk values.

The PARAFORMAT2:
cbSize = 0x0000009c
dwMask = 0x8001003f
wNumbering = 0x0000
wReserved = 0x0000
dxStartInden = 0x00000000
dxRightInden = 0x00000000
dxOffset = 0x00000000
wAlignment = 0x0001
cTabCount = 0x0000
-About the other attributes that belong to the RichEdit2 - all with junk values

RE style: WS_CHILDWINDOW, VISIBLE,CLIPSIBLINGS, MAXIMIZE, VSCROLL, HSCROLL, OVERLAPPED, 000081C4
RE Ex-Style: WS_EX_LEFT, LTRREADING, RIGHTSCROLLBAR, ACCEPTFILES, CLIENTEDGE.
0
 
LVL 49

Expert Comment

by:DanRollins
Comment Utility
Thanks for the great feedback.  

The junk fields are becasue MFC RichEdit supports RE 1.0 which uses the older layout.  I hope that you are not trying that hack that attempts to use RichEdit 2.0 are you?

My settings were different.  Default font was "MS San Serif" and yHeight was 0xa5.  However, when I changed to your settings, my code ran just as fast as ever.  You could try setting to use "Courier New" which is a TT font ("Courier" is not).

=-=-=-=-=-=-=-=-=-=-=-=-  
If there is *anything* unusual about your code, then please start over with a AppWizard created Dialog-based app, add a RE control and procede with testing.

Another thing to check:  As your program starts up, the debug trace window will show the modules that get loaded.  On mine, I see:

Loaded 'C:\WINNT\system32\riched32.dll', no matching symbolic information found.
Loaded 'C:\WINNT\system32\riched20.dll', no matching symbolic information found.

And when I go to that directory and right-click the properties/version shows:

riched32.dll 5.0.2134.1 ("Rich Text Edit Control, v3.0"
Language: English (United States)

riched20.dll 5.30.23.1205 ("wrapper for dll richedit 1.0)
Language: English (United States)

=-=-=-=-=-=-
If yours are different, then you could try this:  Go to the computer that runs quickly and copy these two dlls into your testing executable directory and verify that they get loaded (rather than the ones in the system dir).  See if it makes any difference.

-- Dan
0
 

Author Comment

by:shmuelal
Comment Utility
Hi Dan,

First of all, yes! I'm trying to use this hack that loads the Riched20.dll.
I wanted to color the background of the text and I needed the richedit 2.0 features.
But it doesn't work for some reason so I guess that I do not have the rich edit 2.0.

the versions I got:
riched32.dll 5.00.2134.1
Language: English (United States)

riched20.dll 5.30.23.1203
Language Neutral (???)

In the other computer the version of the riched20.dll was 5.30.23.1200 with the same language.
0
 
LVL 49

Accepted Solution

by:
DanRollins earned 350 total points
Comment Utility
The hack will not work.  You should have mentioned that in the very beginning.

If you can totally avoid using an MFC calls, or any MFC support at all, then you can use RE 2.0  Otherwise forget it.

Since you are not able to do what you want (set background color) anyway, just remove the hack.  Or better yet, start a clean new AppWizard program an try some tests.  I think you'll see that MFC works perfectly with RE 1.0 and will load your files in 500 milliseconds.

-- Dan
0
 

Author Comment

by:shmuelal
Comment Utility
Hi Dan,
I have a good thing to tell you:
I managed to read the file very fast by changing the file opening to be binary and not text.
I got into this conclusion when I've opened a CPP file and I got it corrupted and that is (I assume) because there weren't any \r's.
In binary mode I'm loading in 1 or 2 seconds a file of 150 KB size.

Any way,
Thanks for everything and because of you're bothering I will give you the points you deserve.

Thanks again
Alon Shmuel
0
 
LVL 49

Expert Comment

by:DanRollins
Comment Utility
Thanks for the points.  But I'm not sure what you mean by 'binary mode' Do you mean that when I gave the two examples that showed...

CFile            cFile( "c:\\temp\\testfile.rtf", CFile::modeRead );

...you did something else?  Just curious.

-- Dan
0
 

Author Comment

by:shmuelal
Comment Utility
Yes.
I added the CFile::modeBinary to this line and the file I'm opening is not an RTF but a CPP file.
It is very fast.
I had a problem when I wanted to color the tokens because that I missed the line feader, but I get  over it by reducing from each token position an offset that is equals to the line I'm currently at.
if a file of 150kb was read in 11 seconds, now it takes 1 second!!!
0

Featured Post

Threat Intelligence Starter Resources

Integrating threat intelligence can be challenging, and not all companies are ready. These resources can help you build awareness and prepare for defense.

Join & Write a Comment

Suggested Solutions

In this article, I'll describe -- and show pictures of -- some of the significant additions that have been made available to programmers in the MFC Feature Pack for Visual C++ 2008.  These same feature are in the MFC libraries that come with Visual …
If you use Adobe Reader X it is possible you can't open OLE PDF documents in the standard. The reason is the 'save box mode' in adobe reader X. Many people think the protected Mode of adobe reader x is only to stop the write access. But this fe…
This video will show you how to get GIT to work in Eclipse.   It will walk you through how to install the EGit plugin in eclipse and how to checkout an existing repository.
This video gives you a great overview about bandwidth monitoring with SNMP and WMI with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're looking for how to monitor bandwidth using netflow or packet s…

771 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

12 Experts available now in Live!

Get 1:1 Help Now