Making RichEdit work properly on Windows 10

[jj2007]

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

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

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 or Microsoft Office Compatibility Pack (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).

[zedd151]

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

[jj2007]

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

Is 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

[zedd151]

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

okay, that clarifies a little bit. 

[zedd151]

Is 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

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

[jj2007]

Seems 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

[zedd151]

Seems 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

Okay, but there is a lot of evidence (for both).    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.

[HSE]

Hi JJ!

System Richedit20 think your RTF file is bad formed 

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

[jj2007]

System Richedit20 think your RTF file is bad formed 

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.

[HSE]

Say:

Code Select Expand

{\*\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:

Code Select Expand

\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


[jj2007]

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.

[HSE]

  The "feature" vanished without that text.

[jj2007]

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.

[jj2007]

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

[hutch--]

 

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.