The MASM Forum

After "upgrading" one of my machine to Windows 10, I discovered a glitch in its handling of the RichEdit control:
When launching RichMasm (http://masm32.com/board/index.php?topic=5314.0) the first time, a message box pops up saying "msptls.dll missing".

On further investigation, it turns out that this DLL sits in C:\Program Files (x86)\Common Files\Microsoft Shared\OFFICE12\MSPTLS.DLL, together with the RICHED20.DLL that RichMasm (http://masm32.com/board/index.php?topic=5314.0) loads successfully.

This is fixed for RichMasm in the latest MasmBasic release (http://masm32.com/board/index.php?topic=94.0), and MB coders can test the workaround (attached) with e.g.

include \masm32\MasmBasic\Res\MbGui.asm
  GuiControl MyRich, "richedit"
  SetWin$ hMyRich=FileRead$(CL$())
GuiEnd

Chances are that you will never encounter the "msptls.dll missing" box, because most of the time people simply use
invoke LoadLibrary, chr$("RichEd20.dll") or
invoke LoadLibrary, chr$("msftedit.dll")

Both load the DLL from C:\Windows\System32. While I have not tested the msftedit dll extensively (it looked crappy), I did work a lot with RichEd20. It is buggy, too, but we know our workarounds. What is remarkable, though, is that the System32 version is SLOOOOOW. You won't notice any problems with e.g. \Masm32\Examples\*.asm, but beyond a few hundred lines, loading a file into a richedit control becomes a PITA.

The solution is to use a better version. Only Murray Sargent (https://blogs.msdn.microsoft.com/murrays/) ("I'm a software development engineer in Microsoft Office and have been working mostly on the RichEdit editor since 1994.") knows why M$ offers the crappy DLL in System32, but fortunately, there is a solution: Use the Office version, e.g.:
C:\Program Files (x86)\Common Files\microsoft shared\Office11\RICHED20.DLL
C:\Program Files (x86)\Common Files\microsoft shared\OFFICE12\RICHED20.DLL

RichMasm does this automatically for you, and MB coders can use
  MbLoadRich PROTO
  call MbLoadRich

Put an int 3 in front if you want to discover the magic workaround that makes the Office12 version work on Win10 ;-)

Depending on availability, you get Office11, then Office12, then Sys32.
The fastest one is Office11, O12 is 10% slower, Sys32 is a factor 25 or so slower.

OK, you checked, and that folder doesn't exist :(
On my Win8.1 PC that I "upgraded" to Win10, both folders are present but only Office12 has the DLL in it. That is why I got the error box. No idea whether Office12 is installed by default, and why.

Anyway, M$ is at your service: View, print and copy Word documents, even if you don't have Word installed. This download is a replacement for Word Viewer 2003 (https://www.microsoft.com/en-us/download/details.aspx?id=4)
Install it (24 MB), then discover a new folder and a fast RichEdit control.

EDIT: Attached Mini_Rtf_Reader.exe needs a filename in the commandline, otherwise it throws an exception.

I think you get the speed loss from using RTF rather than plain text. I still use the DLL call to rich edit 2 and because of the plain text only it will load many megabytes quickly.

Quote from: hutch-- on May 25, 2016, 07:46:50 PM
I think you get the speed loss from using RTF rather than plain text. I still use the DLL call to rich edit 2 and because of the plain text only it will load many megabytes quickly.

Hutch,
What you write is correct, but why use a rich edit control for poor text? It is meant for rich text, and there is no excuse that my bigger files load a factor 50 slower with the crappy System32 OS version. Or that msftedit.dll has fat bugs:

If only I could convince the RichEdit50W EM_STREAMOUT message that occasionally "forgetting" a line feed is not an acceptable behaviour (https://blogs.msdn.microsoft.com/murrays/2006/10/19/some-richedit-history/)

Even the man behind RichEdit complains: (https://blogs.msdn.microsoft.com/murrays/2006/10/13/richedit-versions/#comment-2763)

QuoteMurrayS
March 26, 2009 at 12:42 pm   

RichEdit is developed by Microsoft Office and is a basic component in this program suite. Two versions (RichEdit 3.0 and 4.1) are also distributed with Windows. They shipped originally with Office 2000 and Office 2002. We've been hoping to ship a newer version in Windows for some time, but testing the huge backward compatibility scenarios and writing the up-to-date documentation have been stumbling blocks. Comments like yours help increase the priority. Thanks

We are now 2016, 22 years after Murray Sargent started working on it. The latest finest Windows 10 RichEd.DLL is still slow as hell: 20 seconds to load my 1.5MB testbed, instead of 0.8 seconds with the Office version. With the Office11 RichEd20.dll, you can load 80MB of rich text in about 5 seconds. This is ok, but why does the crappy OS version still hang around? To discourage developers from using RichEdit?

This is Microsoft at its best :redface:

P.S.: So far I found 4 versions of RichEd20.dll - note the deliciously consistent versioning system:
C:\Windows\System32\riched20.dll:
Rich Text Edit control v 3.1
5.31.23.1230
NAME: Microsoft Rich Text Edit control version 3.1
473600 bytes, 21 Nov 2010

Office11 folder:
Version 5.0
5.50.99.2050
NAME: Copyright Microsoft 1997-2006
original file name MsftEdit.dll
1103280 bytes, 18 June 2007

Office12 folder:
Version 6.0
12.0.6500.5000
NAME: 2007 Microsoft Office system
1017176 bytes, 26 Feb 2009

Office 2010 (?):
Version 6.0
14.0.4750.1000
NAME: Microsoft Office 2010
1366376 bytes, 1 Oct 2010

My small test with small RTF-file 48 Mb.
riched20.dll:  8727 ms v 3.1
riched20.dll:  1254 ms v 4.0
riched20.dll:  1421 ms v 5.0
msftedit.dll:  2163 ms v 4.1
msftedit.dll:  1911 ms v 7.5 Windows 8.1
msftedit.dll: 12027 ms v 7.5 Windows 10


Doesn't look very plausible. How did you fill the control? Can you post the test?

EDIT: Tim sent me a fat RTF, and I did some tests:
Timings (seconds)
1.1 Office 2010 RichEd20.DLL *)
1.5   Office 2010, version 4 <<< compact and fast, correct as 6.0, added by Tim 26.5.
1.8 Office11 folder
2.2 Office12 folder
15.0 Windows\System32\RichEd20.dll

So we have a clear winner: Tim's Office 2010 version. But check the screenshot below - it loads only 50% of the doc... ::)

Note that the math formulas appear correctly in MS Word and WordPad - they are saved as images, apparently. The doc is 48MB, but saved as plain text, only 0.7MB remain, so there must be plenty of embedded images.

Given that the official Sys32 (last screenshot) is just slow and crappy, the choice is basically between the versions that the free Word viewers (https://www.microsoft.com/en-us/download/details.aspx?id=4) install as C:\Program Files (x86)\Common Files\microsoft shared\Office1?\RICHED20.DLL (see Oct 2013 thread (http://masm32.com/board/index.php?topic=2448.msg25637#msg25637))

The Office11 folder gets filled by the free Word Viewer (https://www.microsoft.com/en-us/download/details.aspx?id=4) (recommended, the best and fastest RichEd20 imho), the Office12 folder by the free Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint File Formats (https://www.microsoft.com/en-us/download/details.aspx?id=3).

One more goodie for those who still stick to this great control: the flags of GETTEXTLENGTHEX 8)

My tests with a 4MB file show that
GTL_PRECISE or GTL_USECRLF or GTL_NUMBYTES
is about a factor 5,000 slower than
GTL_PRECISE or GTL_NUMCHARS

Which probably means that the control maintains an internal counter for the latter combination of flags. Good to know if you deal with large files ;)

Please don't use Windows' riched20.dll. It's only there for compatibility with ancient code. Upgrade to msftedit.dll. It's modern, fast, but doesn't yet support math. Hopefully soon. It did for a while in the Windows 8 beta, but then somebody disabled it  :( The Office riched20.dll is the best version at the moment. RichEdit runs on iOS, Mac, Android, Windows and WinRT. It supports math and now supports LaTeX math input/output as well. My Math in Office blog will have a post on it soon.

Welcome to the Forum, Murray :icon14:

I guess I can speak for everybody: We feel honoured to see one of the fathers of Windows here... (The click moment that helped Windows to survive (http://connectingperspectives.com/web/2012/09/04/the-click-moment-that-helped-windows-to-survive/))

Quote... the professional network of a Microsoft engineer, Dave Weise, was activated at a Friday-night party. He met an old acquaintance, Murray Sargent, a professor at the University of Arizona and an avid programmer. They talked about the Windows 3 technical problems and Sargent suggested a potential solution. They teamed up and started implementing that solution. Some days later, Steve Ballmer, Microsoft's number two executive, went for a jog with Sargent...

Quote from: murrays on April 19, 2017, 09:17:33 AMThe Office riched20.dll is the best version at the moment.

Indeed, my idiosyncratic editor (http://masm32.com/board/index.php?topic=5314.0) has always used, if available, the Office 11 version, which is fast and stable. Only with the latest, math-enabled version, it uses the Office 12 version if the file to open is in SF_BINARY format. So far I have not been able to find a simple example how to implement the linear format for math, which would allow (?) to save the file in "normal" rtf format. If by any chance you have something in your pockets, I'd be grateful to see it.

Welcome to the forum, Murray.  :t

Great work, indeed.

Since you are updating richedit, may we ask some requests for the next versions ?

a) keeping richedit compatible with all windows versions prior to WinXP.
b) More documentation and examples on the Apis usage. Ex: The math functionality on richedit20 is achieved through msptls.dll that have lots of exports and no documentation about the apis of it.
c) making it be easier to use in other applications, and not only the ones related to Office package.

Hi Murray,

Good to see you here. I have been using rich edit controls since the earliest win9x OS versions for pure ascii plain text and in that context the early versions worked well. With the advent of the later versions (2/3), the extra functionality was very useful with multiple levels of undo/redo and certainly fast enough. For a programming editor that preferable uses fixed pitch fonts it has been an excellent tool for years. With the 32 bit version, the editor I write will run on Win2000 upwards

Using the 64 bit version has been no problems at all in Win10 and they also run fine on Win7 64. I have yet to try the later versions as I don't know much about them or how evenly they are supported in different 64 bit versions of Windows.

msftedit.dll: 11326 ms v 8.5 Windows 10 :(

EDIT: Office riched20.dll after v.12 have problems with reading Word2007RTFSpec9.rtf :(

Quote from: guga on April 19, 2017, 12:55:03 PMa) keeping richedit compatible with all windows versions prior to WinXP.

I hope you meant "WinXP and later", Guga.

Re documentation, it is OK in general. The problem is slightly different behaviour sometimes. And little bugs :(

QuoteI hope you meant "WinXP and later", Guga.

Oops...Indeed. Sorry :) :bgrin:

I've set up a little testbed for the various RichEdit versions, see attachment. Extract everything to a folder on the same drive of your Masm32 installation.

- without arguments, each exe loads \Masm32\examples\exampl01\generic\generic.asm
- drag the source itself (SmallEditor.asc) over the exe to see "normal" rtf
- open or drag SF_BINARY_Good.rmm over the exe to see the behaviour with math and binary format

There are executables for the Office 10, 12, 14 and 15 DLLs.

On my Win7-64 machine,
- Office 11 can't load SF_BINARY format
- Office 12 handles the math correctly (display OK, you can edit the text)
- Office 14 can load the file but the display is garbled (normal RTF is handled correctly)
- Office 15 can load the file and the display is OK, but if you put the cursor behind EndOfCode and hit Return, prepare for trouble (normal RTF is OK)
- Sys32\MsftEdit can't load the math doc (SF_BINARY_Good.rmm), everything else is OK.

On my Win10 machine,
- Office 11 can't load SF_BINARY format
- Office 12 handles the math correctly (display OK, you can edit the text)
- Sys32\MsftEdit can load the math doc but the display is minimally garbled, i.e. EndOfCode and How to are in the same line; however, in contrast to Office 15 on Win7, you can edit the text without major problems 8)

Saving is disabled simply because this tests only the loading.

You can use RichMasm (http://masm32.com/board/index.php?topic=5314.0) for math editing, it uses Office12 for the math template (menu File/New Masm source/math) and can save the format. It will warn you if an edit corrupts the file. The procedure is hilarious:
- user types something
- if control is idle for a few seconds, text is EM_STREAMED out to disk
- immediately after, text is EM_STREAMED in to an auxiliary control
- if that control remains empty because the file got corrupted, a MsgBox pops up and invites you to UNDO that edit.

Note that very few formulas corrupt the file. So far, I've found only two - marked in red in the *.rmm file. Both are taken from Murray's own guide (http://unicode.org/notes/tn28/UTN28-PlainTextMath-v2.pdf); all other formulas resp. autocorrect options work just fine.

Enjoy - this is really powerful for adding mathematical formulas to your assembler sources, but be careful - frequent backups please...  8)

Building the source requires MasmBasic of 21 April 17 (http://masm32.com/board/index.php?topic=94.0) - making all DLLs load correctly required some tweaking, but now it works for all of them.

Have you checked to see if the one you want is on the redistributable list ?

Quote from: hutch-- on April 21, 2017, 08:18:06 PM
Have you checked to see if the one you want is on the redistributable list ?

In case you are worried about copyright issues: The exe will tell you that the DLL is not available. Office 11+12 get installed with WordViewer and the compatibility pack, while 14+15 get installed with Office. So you either have them (legally, hopefully), or the testbed will not work for the versions that you don't have...

MsFtEdit version show text almost correctly in Windows 8.1 and Windows 10 :t

After running that test program, the v.14 don't work any more  ;) So M$ self-destruction works :P

Quote from: TWell on April 21, 2017, 09:02:34 PM
After running that test program, the v.14 don't work any more  ;) So M$ self-destruction works :P

Ouch. What exactly happened? I have had no problems so far... the situation is stable as described in reply #13. (http://masm32.com/board/index.php?topic=5383.msg65459#msg65459) The C:\Program Files (x86)\Common Files\microsoft shared\OfficeXX folders are write-protected, too. And the proggies don't write to the registry.

Hi all,
very interesting topic!  We are currently encountering performance issues with TRichEdit since being upgraded to Windows 10.

The application we are making in written in Delphi, when I check with procexp.exe I can see that the dll that gets loaded is : C:\Windows\SysWOW64\riched20.dll (which is the slow one I guess.  I have placed the office version of Riched20.dll in the root of my application but it still load the SysWOW64 version.  How can I force (in Delphi) that the dll in the application root directory would be used?

Good question! Normally, LoadLibrary + GetProcAddress are the right tools to do so, but I have no experience with Delphi. Do you have sample code? A minimum window with the RichEdit control only?

https://forums.embarcadero.com/thread.jspa?messageID=771188&tstart=0

Delphi 3:
riched32.dll
C:\Windows\SysWOW64\riched32.dll
riched20.dll
C:\Windows\SysWOW64\riched20.dll

Test program loads riched20.dll from application dir, also in Windows 10.
procedure TForm1.FormCreate(Sender: TObject);
var h : THandle;
        buf: ARRAY[0..256] OF Char;
begin
     h := GetModuleHandle('riched20.dll');
     GetModuleFileName(h, buf, 256);
     RichEdit1.Text := buf;
end;


I do occasionally use RTF in my recent help files and I have little reason to change from the riched 2/3 that I have used for years. The 64 bit version works fine, I have little interest in word processor emulation and no use for any serious maths notation. For plain text mono spaced fonts, these work remarkably well, very fast and with very large capacity.

All this is interesting but it doesn't answer the OP's question.

Quote from: vintech on February 20, 2019, 03:18:12 AMI have placed the office version of Riched20.dll in the root of my application but it still load the SysWOW64 version.  How can I force (in Delphi) that the dll in the application root directory would be used?

Quote from: jj2007 on February 20, 2019, 07:00:06 PM
All this is interesting but it doesn't answer the OP's question.

Quote from: vintech on February 20, 2019, 03:18:12 AMI have placed the office version of Riched20.dll in the root of my application but it still load the SysWOW64 version.  How can I force (in Delphi) that the dll in the application root directory would be used?

I gave a link to the solution.
You need to edit comctrls.pas unit, modify it to load C:\Windows\System32\MSFTEDIT.DLL, changing the classname reference to RichEdit50W. Then you compile comctrls.pas and drop the compiled unit in the pertinent folders. This may be a delicate operation, all depend on the affected dependencies, so if the user is a full noob, an alternative is copy comctrls.pas to the project folder and modify it for the current project only.
I have done the first option sometime in the past and I am sure there are full instructions somewhere in the internet, but am too lazy to look for them now.

Since richedit will always be a basic el cheapo editor, no matter its version, for serious uses it is recommended to fork a few hundred bucks and purchase TRICHEDIT (http://www.trichedit.com/trichedit.html) . I did it for some private projects and have also used it in a small freeware I have in the website. Amazing.

Quote from: AW on February 20, 2019, 08:55:44 PMI gave a link to the solution.
You need to edit comctrls.pas unit, modify it to load C:\Windows\System32\MSFTEDIT.DLL

OP wants to use the Office version, which resides (typically) in C:\Program Files (x86)\Common Files\microsoft shared\OFFICE12\RICHED20.DLL (and there are good reasons to load that one).

OP says that despite placing this DLL in the exe's folder, it does not load that one.

Perhaps it's better to use sysinternals procmon to see if program try to load riched20.dll and if it failed.
Process Monitor (https://docs.microsoft.com/en-us/sysinternals/downloads/procmon)

And what about MSPTLS.dll? Is it also in the app folder?
Probably the OP has already found the problem.

Quote from: AW on February 20, 2019, 10:25:45 PM
And what about MSPTLS.dll?

Good point! The control loads without it, but it leads to crashes further on.

Hi folks,

I'm in the process of converting RichMasm from the Ansi to the Unicode version of the RichEdit control, and stumbled over some new surprises (tested on Win7-64):

1. When loading an identical document in...
  a) %CommonProgramFiles%\Microsoft shared\Office12\RichEd20.dll
  b) C:\Windows\System32\msftEdit.dll with class name RichEdit50W

... they display differently if you used the line spacing feature, e.g. to make a new CASE look better:

(http://www.jj2007.eu/pics/OfficeVsMsftedit.png)

2. The class name: RichEdit50W doesn't work with SF_BINARY (https://devblogs.microsoft.com/math-in-office/richedit-html-support/) files, but RichEdit20W loads them properly.

3. With msftEdit, RICHEDIT50W misbehaves regarding the spacing problem but loads long rtf docs twice as fast as the  RICHEDIT20W version.

See also RICHEDIT diferences between RICHEDIT50W and RichEdit20A (http://masm32.com/board/index.php?topic=8678.0) (ToutEnMasm).

There used to be a serious bug in the RichEdit50W version, see MSFTEDIT.dll aka RichEdit 4.1 aka RichEdit50W (http://www.masmforum.com/board/index.php?topic=13089.msg101564#msg101564), but I don't know if it has been fixed (it's not easy to reproduce) :cool:

It's a never ending story: I found a bug in msftedit.dll, the EM_EXSETSEL message doesn't work properly.

Attached a test case. In the menu, there are six possible selections; only the last one fails with the msftedit.dll control. It does set the cursor to the desired end position (chrg.cpMax), but the start position is erroneously set to cpMax, too.

It's a bug, dear friends in Redmond :cool:

Full source and exe attached, pure Masm32 SDK. Btw the EM_GETTEXTRANGE message works fine :thumbsup:

Note the upper RichEdit control will only show if you are proud owner of ...
C:\Program Files (x86)\Common Files\Microsoft Shared\OFFICE11\RichEd20.DLL or
C:\Program Files (x86)\Common Files\Microsoft Shared\OFFICE12\RichEd20.DLL
... which usually means you have MS Office installed or you have one of the free viewers, i.e. MS Word Viewer (https://filehippo.com/download_word-viewer/) or Microsoft Office Compatibility Pack (https://filehippo.com/download_microsoft_office_compatibility_pack_for_word_excel_and_powerpoint_file_formats/) (if not, grab them before it's too late - Microsoft has discontinued them)

To test it, extract the archive to a temp folder and launch the executable.

P.S.: It turns out this bug has been fixed in Windows 10. However, software should be backwards compatible at least to Windows 7 IMHO (I don't really care for XP, although I loved it).

Quote from: jj2007 on December 10, 2022, 02:00:11 AM
...
Note the upper RichEdit control will only show if you are proud owner of ...
C:\Program Files (x86)\Common Files\Microsoft Shared\OFFICE11\RichEd20.DLL or
C:\Program Files (x86)\Common Files\Microsoft Shared\OFFICE12\RichEd20.DLL
...

Did you ever consider that maybe those versions were not meant for general purpose use? Do they work as intended for MS Word and other OFFICE products? Might be a reason why they are not in System32 directory or otherwise included in any OS. Just a thought.


Is this confined to a particular version of Windows?

Hi Z,

Valid point but the buggy one is actually the one destinated for public use. I filed a bug report (kind of) at Microsoft (https://learn.microsoft.com/en-us/answers/questions/1123169/em-exsetsel-bug-in-msfteditdll-richedit50w.html) :cool:

Quote from: zedd151 on December 10, 2022, 02:46:03 AMIs this confined to a particular version of Windows?

Win7-64. I just checked on my Win10 machine, and yep, no bug. Unfortunately the Win10 msftedit.dll won't get loaded on Win7 :sad:

Quote from: jj2007 on December 10, 2022, 02:51:28 AM
Hi Z,

Valid point but the buggy one is actually the one destinated for public use. I filed a bug report (kind of) at Microsoft (https://learn.microsoft.com/en-us/answers/questions/1123169/em-exsetsel-bug-in-msfteditdll-richedit50w.html) :cool:

okay, that clarifies a little bit.  :biggrin:

Quote from: jj2007

Quote from: zedd151 on December 10, 2022, 02:46:03 AMIs this confined to a particular version of Windows?

Win7-64. I just checked on my Win10 machine, and yep, no bug. Unfortunately the Win10 msftedit.dll won't get loaded on Win7 :sad:

That narrows it down at least. Seems MS is moving away from backwards compatibility, to enforce the switch to more "modern" operating systems 10/11/??.

Quote from: zedd151 on December 10, 2022, 03:03:51 AMSeems MS is moving away from backwards compatibility, to enforce the switch to more "modern" operating systems 10/11/??.

Never assume intention when incompetence can explain the problem :cool:

Quote from: jj2007 on December 10, 2022, 03:06:21 AM

Quote from: zedd151 on December 10, 2022, 03:03:51 AMSeems MS is moving away from backwards compatibility, to enforce the switch to more "modern" operating systems 10/11/??.

Never assume intention when incompetence can explain the problem :cool:

:biggrin: :biggrin: :biggrin:
Okay, but there is a lot of evidence (for both).  :tongue:  And the major software vendors are following suit in regards to scrapping backward compatibility. I'd rather get all of my molars pulled without anesthesia than give in to the visual.net 4.xxx runtime garbage or anything that requires it. And the html and certificate shenanigans that render otherwise good web browsers obsolete (but that's another discussion) Good thing my computer is not compatible with Windows 11 (older TPM module) so I can run windows 10 begrudgingly when necessary, without nags to upgrade to 11. So it seems that hardware vendors are also on the bandwagon in some respects for upgrading to Windows 10 and above. But now I am going off on a tangent, whoops.

Hi JJ!

System Richedit20 think your RTF file is bad formed  :biggrin:

Middle and Lower edits work exactly the same with an Word created rtf:

Quote from: HSE on December 10, 2022, 03:46:49 AM
System Richedit20 think your RTF file is bad formed  :biggrin:

Prove it, Hector. WordPad, MS Word, RichEdit50W and RichEdit20W do not show any error here on my Win7 and Win10 machines. Btw the file you posted is a factor 23 bigger than my original file, so you evidently tinkered with it - not helpful.

Say:{\*\generator Riched20 12.0.6768.5000;}\viewkind4\uc1
\pard\sl240\slmult0\tx1000\tx1400\tx4800\tx5800\tx0\cf1\b\v\f0\fs20\lang2055\'b0B$;003J003J0026-z574b1T105k003u4000033oldr msge048addr msge063ediC msge003ebxE WM_e008CASE WM_e004PtDC msge002pson msge004Icon msge008ADDR msge00n000970009008L0009006k0005005w0008005W3508005g0008tU0kc0Vn#\b0\v0\f1\fs24\lang1040   ret\tab\tab\tab\cf2 ; \cf1 retn 4*#args\cf2\par

Try:\viewkind4\uc1\pard\sl240\slmult0\tx1000\tx1400\tx4800\tx5800\tx0\cf1\lang2055\b\v\f0\fs20\lang1040\b0\v0\f1\fs24   ret\tab\tab\tab\cf2 ; \cf1 retn 4*#args\cf2\par


Why should I "try"? There is hidden text in it, so what? It's legit, and it has nothing to do with the problem of this thread.

 :biggrin: The "feature" vanished without that text.

I know I shouldn't feed the troll, but anyway, here's a version with guaranteed no hidden text. 1282 bytes of plain rtf, readable by MS Word, WordPad, RichMasm, TinyIDE without any problems.

Besides, the Office and System32 versions of RichEd20.dll have no problem in selecting the ranges of text. Even the System32\MsftEdit.dll version can select the second text, but now it's the first one that displays this behaviour.

It's clearly a bug in MsftEdit.dll, and apparently it has been fixed in Windows 10, but that doesn't help those who are still coding for Windows 7 clients.

Source and testfile attached, plain Masm32 SDK code.

Just tested msftedit.dll in XP and Win7:
- in Win 7, pressing Ctrl 5 inserts some space before the current line
- in WinXP, pressing Ctrl 5 inserts some space after the current line

 :tongue:

Now you know why I stick to richedit 3, its reliable, does text mode correctly, OK at RTF and I know at least some of its bugs.  :wink2:

QuoteI filed a bug report (kind of) at Microsoft :cool:

Very interesting reading indeed!
Looks very much like you are talking wtih MS GPT3 dumb robot :)

Quote from: jj2007 on December 10, 2022, 10:47:00 AMOffice and System32 versions of RichEd20.dll have no problem in selecting the ranges of text. Even the System32\MsftEdit.dll version can select the second text, but now it's the first one that displays this behaviour.

It's clearly a bug in MsftEdit.dll, and apparently it has been fixed in Windows 10, but that doesn't help those who are still coding for Windows 7 clients.

Update: Yes, this bug has been fixed in Windows 10, but the price to pay is a msftedit.dll version that is roughly a factor 3 slower for loading big files - see Beta testers please (http://masm32.com/board/index.php?topic=10401.msg117564#msg117564).

Attached a testbed demonstrating that the EN_LINK notification is broken in the Windows 10 version of msftedit.dll

Extract all files to a folder and launch the exe (it's pure Masm32 SDK code, no MasmBasic involved).

You will see two RichEdit controls side by side. One uses the Win7 msftedit, renamed to msftedjj.dll, the other one the standard Windows System32 version.

When hovering over the links, cpMin is shown above the controls. It's different.

Source attached.

Below three versions of the RichEdit control for comparison, to be run on Windows 10 (or Win11 - any volunteers?).

The attached program (with source; plain Masm32 SDK) loads the same identical rtf file into three controls created with
a) C:\Windows\System32\msftedit.dll
b) same but dll stolen from Windows 7 (minimally modified; PM me for details)
c) C:\Program Files (x86)\Common Files\Microsoft shared\Office12\RICHED20.DLL

- for all three controls, it sets the EN_LINK style for the range 555...666 and 777...888
- the link style is set automatically for the examples links
- note the extra spacing introduced only by the Win10 msftedit
- note the different "automatic" ranges selected only by the Win7 msftedit; they are one off per link
- note the selected text ranges: tText... for Win10+Office12, extText for Win7

The msftedit-based control on Win XP (not shown here) behaves exactly like the Win7 version. It is therefore likely that Microsoft, in the process of fixing the EM_EXSETSEL bug (https://learn.microsoft.com/en-us/answers/questions/1123169/em-exsetsel-bug-in-msftedit-dll-richedit50w) for Win10, introduced a new bug.

(http://www.jj2007.eu/pics/RichEd3.png)

I guess it depends on you reason for choosing later rich edit versions. I have been using richedit 2 and 3 since the XP days because they are at least consistent. They definitey do have their own bugs but with enough practice, you can work around them. It depends on what your target is, if you want word processing, spreadsheet functionality and other additions, apparently the later versions can do this but the earlier rich edit versions do plain text very well and RTF with no problems.

With the earlier versions, you don't have to look for better versions in Word or whatever else, software written for the earlier versions work from XP upwards (I forget how Win 2000 worked).

Quote from: hutch-- on January 27, 2023, 09:15:35 AMWith the earlier versions, you don't have to look for better versions in Word or whatever else

For about 10 years, I used the Office11 and Office12 versions; now I switched to sys32\msftedit because a) it's the officially recommended one, b) everybody has it, from XP onwards, and c) it goes beyond Sys32\RichEd20.dll in several aspects, such as Unicode and speed.

My main reason for switching, though, is speed. When you have sources in the megabyte range, it takes ages to load them with Sys32\RichEd30.dll; the Win7 version of msftedit.dll is a factor 20 or so faster.

Microsoft's handling of this control is not professional.

I gather that your main usage is RTF which is always slower than plain text due to its size and complexity.

One more fat RichEdit bug in Windows 7 (https://support.microsoft.com/en-us/topic/an-application-that-uses-the-richtextbox-control-cannot-display-an-rtf-file-correctly-in-windows-7-or-in-windows-server-2008-r2-a054ea79-0e07-f317-0018-239d089932eb) (signalled by Limitless Technology (https://learn.microsoft.com/en-us/answers/questions/1164654/any-chance-that-the-richedit-mess-gets-fixed?page=1&orderby=Helpful&comment=answer-1169513#newest-answer-comment)):

QuoteAn application that uses the RichTextBox control cannot display an .rtf file correctly in Windows 7 or in Windows Server 2008 R2

QuoteTo create a sample test file, paste the following lines in Notepad, and then save the file as an .rtf file.

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fswiss\fcharset0 Arial;}
{\f43\froman\fcharset163\fprq2{\*\panose 00000000000000000000}Times New Roman CYR (Vietnamese{\*\falt Times New Roman};}
}
{\*\generator Msftedit 5.41.15.1515;}\viewkind4\uc1\pard\f0\fs20 hello there... this is a sample document\par
\par
}

The Micros*t page continues to say: A supported hotfix is available from Microsoft. If one of you is able to find that hotfix, I owe you a beer or two.

I attach the test file. It should display the string "hello there... this is a sample document", and does so in MS Word but not in WordPad or RichMasm on Windows 7.

RichMasm of 2 February 2024 (included here (http://masm32.com/board/index.php?topic=94.0)) takes care of one more exotic bug:

When selecting a range of text where the start is in visible text but the end is inside a hidden text range, the control ignores the start value and sets start and end to the same value inside the hidden text.

With RichMasm, if that happens (a rare event), a MsgBox pops up to instruct the user how to deal with it.

There is one bug for which I can't give an official fix (PM me if you need one): Certain big rtf files (over 2MB) don't get loaded at all with the Win10 version of System32\msftedit.dll - the control just hangs, keeping its cpu core busy.

Shame on you, Microsoft, that you can't produce a RichEdit control that simply works as it should. Murray Sargent, responsible for the control in the last decades, loves talking about exotic features (https://devblogs.microsoft.com/math-in-office/) but is apparently not interested/not willing/not able to fix its serious bugs. Given the overwhelming importance of a control that is able to display more than plain text, and the fact that Windows has arrived at several Gigabytes of bloated code, this is a shame for the whole software industry.

One more bug in the Win10 System32\msftedit.dll: abnormal character spacing for the system font (other fonts are not affected).

Normal MS cripled code.
This was a culprit.
CYR (Vietnamese

Another goodie, quoting M$ Learn EM_STREAMOUT (https://learn.microsoft.com/en-us/windows/win32/controls/em-streamout):

QuoteSF_USECODEPAGE
Rich Edit 3.0 and later: Generates UTF-8 RTF and text using other code pages. The code page is set in the high word of wParam. For example, for UTF-8 RTF, set wParam to (CP_UTF8 << 16) | SF_USECODEPAGE | SF_RTF.

So performing the streamout with...
SF_UTF8=CP_UTF8 shl 16 or SF_USECODEPAGE or SF_RTF... writes indeed a lot of rtf code to the file.

Instead of the usual {\rtf1\, the file starts with {\urtf1\ :thumbsup:

Congrats, Micro$oft! You have made it possible to save text to Utf8 Rtf format.

Now the next step might be to convince your popular Windows applications Notepad, WordPad and MS Word that this new innovative format is not plain text (see image below) but rather a variant of the Rich Text Format :cool:

P.S.: Micros*t suggests (https://answers.microsoft.com/en-us/windows/forum/all/windows-10-and-family-tree-maker/02e5f3e7-ef6e-4977-859a-d61ae8ab870b) to "reinstall the application" :cool: