[2 days left] What’s wrong with your cloud strategy? Learn why multicloud solutions matter with Nimble Storage.Register Now

x
?
Solved

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

Posted on 2002-06-03
66
Medium Priority
?
1,857 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
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 32
  • 16
  • 9
  • +3
66 Comments
 
LVL 12

Expert Comment

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

Expert Comment

by:Roshan Davis
ID: 7050579
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
ID: 7050584
So how they do it in the Visual Studio?
Can I write a CLLBACK function that overrides the one in the MSDN?
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 

Author Comment

by:shmuelal
ID: 7050614
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
ID: 7050622
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
ID: 7050950
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
ID: 7052086
>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
ID: 7053288
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
ID: 7053294
>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
ID: 7053302
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
ID: 7053316
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
ID: 7053619
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
ID: 7053620
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
ID: 7055621
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
ID: 7055656
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
ID: 7055784
You right.
But I look at the visual studio's speed.
How did they do it?
0
 
LVL 3

Expert Comment

by:GGRUNDY
ID: 7055838
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
ID: 7055841
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
ID: 7055878
I would be very glad to see some code.
0
 

Author Comment

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

Expert Comment

by:DanRollins
ID: 7056896
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
ID: 7058400
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
ID: 7058516
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
ID: 7058647
Hi!
also speed of loading depends on document complexity.
0
 

Author Comment

by:shmuelal
ID: 7058658
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
ID: 7058682
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
ID: 7060094
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
ID: 7060843
>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
ID: 7065024
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
ID: 7065170
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
ID: 7065262
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
ID: 7065264
I appreciate the time you invest, so I raised the points for this question.
0
 
LVL 12

Expert Comment

by:migel
ID: 7065357
Hi!
can you show part your RTF file?
0
 

Author Comment

by:shmuelal
ID: 7066120
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
ID: 7066282
Hi!
why you use SF_RTF flag to load just text (cpp) file?
0
 
LVL 49

Expert Comment

by:DanRollins
ID: 7066326
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
ID: 7068986
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
ID: 7069239
hi!
may be main problem in your processor?
0
 

Author Comment

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

Expert Comment

by:migel
ID: 7069342
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
ID: 7069476
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
ID: 7069515
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
ID: 7069589
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
ID: 7069646
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
ID: 7069833
code for loading cpp file please :-)
0
 

Author Comment

by:shmuelal
ID: 7069895
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
ID: 7070511
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
ID: 7071865
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
ID: 7072292
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
ID: 7072353
OK,
there is an improvement.
but now I can't colorize the code.
0
 
LVL 12

Expert Comment

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

Author Comment

by:shmuelal
ID: 7072723
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
ID: 7073215
>>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
ID: 7074637
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
ID: 7074714
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
ID: 7074842
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
ID: 7074899
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
ID: 7074961
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
ID: 7074980
Also, use Spy++ and report the style codes of the RE control. -- Dan
0
 

Author Comment

by:shmuelal
ID: 7075069
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
ID: 7076506
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
ID: 7077544
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 1400 total points
ID: 7077614
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
ID: 7103098
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
ID: 7104989
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
ID: 7105182
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

Ask an Anonymous Question!

Don't feel intimidated by what you don't know. Ask your question anonymously. It's easy! Learn more and upgrade.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This is to be the first in a series of articles demonstrating the development of a complete windows based application using the MFC classes.  I’ll try to keep each article focused on one (or a couple) of the tasks that one may meet.   Introductio…
Introduction: Finishing the grid – keyboard support for arrow keys to manoeuvre, entering the numbers.  The PreTranslateMessage function is to be used to intercept and respond to keyboard events. Continuing from the fourth article about sudoku. …
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.
In this video, Percona Solutions Engineer Barrett Chambers discusses some of the basic syntax differences between MySQL and MongoDB. To learn more check out our webinar on MongoDB administration for MySQL DBA: https://www.percona.com/resources/we…

649 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