Making RichEdit work properly on Windows 10

[jj2007]

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...

[TWell]

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

[jj2007]

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. The C:\Program Files (x86)\Common Files\microsoft shared\OfficeXX folders are write-protected, too. And the proggies don't write to the registry.

[vintech]

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?

[jj2007]

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?

[aw27]

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

[TimoVJL]

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.

Code Select Expand

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;


[hutch--]

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.

[jj2007]

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

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?

[aw27]

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

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?

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 . I did it for some private projects and have also used it in a small freeware I have in the website. Amazing.

[jj2007]

I 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.

[TimoVJL]

Perhaps it's better to use sysinternals procmon to see if program try to load riched20.dll and if it failed.
Process Monitor

[aw27]

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

[jj2007]

And what about MSPTLS.dll?

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

[jj2007]

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:



2. The class name: RichEdit50W doesn't work with SF_BINARY 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 (ToutEnMasm).

There used to be a serious bug in the RichEdit50W version, see MSFTEDIT.dll aka RichEdit 4.1 aka RichEdit50W, but I don't know if it has been fixed (it's not easy to reproduce)