MSFTEDIT.dll aka RichEdit 4.1 aka RichEdit50W

[jj2007]

Hi all,

Does anybody have experience with the RichEdit50W version? I was trying to get a clue why RichMasm loads big sources a bit slowly, and discovered that the RichEdit50W needs 200 ms to stream in a 12,000 lines file, instead of 5800 ms for RichEdit20A...

The doc loads OK with RichEdit50W, but I expect it to be a nightmare to translate my 24 EM_FINDTEXT messages to Unicode ::)

[jj2007]

No replies... ::)

Just found out that there is a small difference between RichEdit20A and RichEdit50W: The latter does not stream out hidden text in plain text mode. Equally undocumented is a disk space saving feature: 50W swallows occasionally the CrLf, so that

Code Select Expand

MyProc endp
.data
becomes

Code Select Expand

MyProc endpdata
Long live Microsoft :8)

[hutch--]

JJ,

With the irritations of RichEdit20A I am in no hurry to try out the later ones.

[jj2007]

With the irritations of RichEdit20A I am in no hurry to try out the later ones.

Hutch,
I fully understand :bg
Just posted the following on Murray Sargent's blog - he seems to be the lead author of the RichEdit control:

re: Some RichEdit History
Saturday, January 09, 2010 6:10 AM by jj2007

I have written a RichEdit20A-based editor and use it on a daily basis. Since my source code is growing, loading gets slower and slower: about 6 seconds by now. So I tested if RichEdit50W is any faster - and yep, it is: EM_STREAMIN is a factor 30 (!) faster for RTF files in the half Megabyte range. Great. If only I could convince the RichEdit50W EM_STREAMOUT message that occasionally "forgetting" a line feed is not an acceptable behaviour...

For the initiated: The dropped linefeed happens in this section, seen through a normal text editor:

Code Select Expand

FormatCopy endp\par
\par
.data\par


Such simple straightforward RTF translates, when saved as plain text, into ...

Code Select Expand

FormatCopy endp

.data

... for RichMasm (based on RichEdit20A) and MsWord 2003, but into...

Code Select Expand

FormatCopy endpdata

...for WordPad (based on RichEdit50W) and my own tests with that version. So it is clearly a fat RichEdit 4.1 bug, a product for which I have paid when I bought my Win XP license.

[hutch--]

JJ,

I take a very minimalist approach to RichEit controls, I only shifted from richedit 1.0 to the later version to get the unlimited undo/redo capacity and with that option the line reporting was buggy and I had to write a messy workaround for it. Without this the autoindent was unreliable as was the tab replacement with spaces. I long ago tried syntax colouring with rich edit using the published API methods and it was appallingly slow. Iczelion's technique works well as it just reads the content of the window and displays it using a different API. It can be got almost reliable but the code is a cluttered mess and its a bit fussy about the font you use.

For plain text its upside is is fast, reliable, has multiple level redo/undo and is just a bit more reliable with fore and background colours but it has never been a joy to work with and its nothing like as solid as the old version 1.0.

[jj2007]

JJ,
I take a very minimalist approach to RichEit controls, I only shifted from richedit 1.0 to the later version to get the unlimited undo/redo capacity and with that option the line reporting was buggy and I had to write a messy workaround for it.

Hutch,

I have become a real expert for messy workarounds, but in the end I got them to work. RichMasm may not be everybody's taste, but the formatting helps me a lot to understand my own code. Like keeping track of push & pop by marking them red, or using a specific background colour for highlighting a loop.

The only drawback is that loading big sources has become slow - one second per 2,000 lines is negligible for 99% of the code posted here, but the RichMasm source is at 12,000 lines now, so it takes 6 seconds until I see my code. Fortunately, saving is a lot faster, in the milliseconds range.

Nonetheless, when I stumbled over the fast loading of RichEdit 4.1, I was tempted to try that one. I have timed it again, it is a factor 15 for RTF sources (although 4.1 is actually a bit slower for plain text). Only to discover that its EM_STREAMOUT is seriously broken. Which might explain why .NET sticks with version 3.0:

Posted August 01, 2007, 12:31 by nobugz, MVP, Moderator:

The .NET RichTextBox control uses a pretty old version of the native Windows RichText control.  It simply does not support \par in table cells.  I noticed that the XP version of Wordpad.exe does support it.

The page you are looking at is full of formatted text. "Rich text" is ubiquitous, and it is an absolute must that an OS, called "Windows", "BloatOS" or whatever, provides a control that handles rich text in an efficient way. It will not bloat the OS further: the 539136 bytes of msftedit.dll represent 0.0036% of the disk space required for Vista. What I find appalling, and very difficult to explain unless you adopt the view that Microsoft tries to block competition, is that this control is badly documented and broken.

[lingo]

"Iczelion's technique works well as it just reads the content of the window and displays it using a different API."
For plain text may be but for Rich Text with different fonts colors, subscript, superscript...etc, different styles and paragraphs it doesn't work. (See the Pic1)

"I long ago tried syntax coloring with rich edit using the published API methods and it was appallingly slow." by Hutch
The same opinion as Iczelion:

"RichEdit control provides EM_SETCHARFORMAT message that you can use to change the color of the text. At first glance, this message seems to be the perfect solution (I know because I was one of the victim). However, a closer examination will show you several things that are undesirable:
- EM_SETCHARFORMAT only works for a text currently in selection or all text in the control. If you want to change the text color (highlight) a certain word, you must first select it.
- EM_SETCHARFORMAT is very slow
- It has a problem with the caret position in the richedit control
With the above discussion, you can see that using EM_SETCHARFORMAT is a wrong choice. I'll show you the 'relatively correct' choice." by Iczelion from Tutorial 35: RichEdit Control: Syntax Highlighting "

With other words don't use  RichText!!!
But I disagree with both because I like RichText different formatting and managed to implement fast syntax coloring with EM_SETCHARFORMAT.
Of course I implemented heavy speed optimization of the code.

For Example:  -To find a single control word from the current line in the list with control words Iczelion started every time to search from the 1st word in the list and complains:

"The really complicated part is when we have to find a fast way of searching for the words to be highlighted. This is further complicated by the need notto hilight any word within a comment block." by Iczelion

I implemented Red Black Tree searching with 256 tables with addresses for the 256 Root trees for different symbols.   (See the Pic2)

[hutch--]

Lingo,

Its an interesting effect with the different sized fonts and colour. I have too many years practice reading fixed pitch fonts and I find variable pitch hard to read for code and as a personal prejudice syntax hilighting gives me eyestrain and I read it much slower. When I did the syntax hiliting I used a hash table written in assembler that used the variable length string engine for the basic compiler I used to use for QE and it was always faster than you needed for a text editor, it was designed for another purpose but when I wrote the new version in MASM I did not bother to write the code as I will personally never use it.

[jj2007]

Lingo,

Its an interesting effect with the different sized fonts and colour. I have too many years practice reading fixed pitch fonts and I find variable pitch hard to read for code and as a personal prejudice syntax hilighting gives me eyestrain and I read it much slower.

Although I have enjoyed syntax highlighting for many years in GfaBasic, I tend to agree with Hutch. Automatic colouring does not help understanding the code. But individual formatting à la RichMasm has its merits:

PrintRTF proc
LOCAL fSuccess:SDWORD
LOCAL hPrDC:DWORD

The S is so easy to overlook that a year after coding this you will have forgotten that this variable, exceptionally, was signed. Another example:

   movi ecx, GENERIC_WRITE
     movi edx, CREATE_ALWAYS
     .if IsRead
      movi ecx, GENERIC_READ
      movi edx, OPEN_EXISTING
   .endif
   invoke CreateFile, esi, ecx, FILE_SHARE_READ, 0, edx, FILE_ATTRIBUTE_NORMAL, 0
   .if eax!=INVALID_HANDLE_VALUE
      mov hFile, eax
      mov editstream.dwCookie, eax
      push edi
      mov edi, offset WinTitleBuffer
      invoke lstrcpy, edi, offset AppName
      invoke lstrcat, edi, esi
      sm hWin, WM_SETTEXT, 0, edi
      pop edi
      movi ecx, EM_STREAMOUT
      and StreamMode, 0
      movi esi, SF_RTF
      .if IsRead
         inc StreamMode
         invoke SetFocus, hEdit               ; give the focus to the edit window
         sm hEdit, EM_SETTARGETDEVICE, 0, 0         
         invoke ReadFile, hFile, addr Read4, 4, ADDR dwBytesRead, 0
         invoke SetFilePointer, hFile, 0, 0, FILE_BEGIN
         mov eax, Read4
         or eax, 20200000h      ; force lowercase for tr
         .if eax!="tr\{[/b]"
            mov esi, SF_TEXT   ; rtf if you find the magic string
         .endif
            movi ecx, EM_STREAMIN
        .endif
      mov editstream.pfnCallback, StreamRTF      ; 187/2718 for asc, 14.5*; 47/32 for WinInc
;      push rv(GetTickCount)
      sm hEdit, ecx, esi, addr editstream
;      invoke GetTickCount
;      pop edx
;      sub eax, edx
;      MsgBox 0, str$(eax), "Hi", MB_OK
      invoke CloseHandle, hFile

I guess the sparingly highlighted parts make it far easier to understand what this code does. From a maintenance perspective, it is a feature I would seriously miss.

Back to my rant on RichEdit 4.1:

"In 2000 a leaked memo from Microsoft obtained by Mary Jo Foley (of Microsoft-Watch) revealed that Windows 2000 was released with 20,000 bugs and that Microsoft knowingly released it any way. After this incident, Microsoft would not speak to Mary Jo Foley for two years regarding projects and information of any kind."

(BoycottNovell)
No wonder they had no time to check something as useless as a formatted text control ::)