RichEdit: Windows 10 version of msftedit.dll is broken

For those of you who use the RichText box, here is a post describing a few oddities.

I'm afraid it's not VB6 but Assembly code, but IMHO it's important to know that there are significant differences between recent versions of System32\msftedit.dll:

The program 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
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 for Win10, introduced a new bug (the control also became 5 times slower, but that's another story).

Attachment 186770

I've been playing with RichEdit controls myself (riched20.dll) just for their ability to handle Unicode (don't need any of the fancy formatting). However I do have a question for you seeing that you are knowledgeable on the subject.

Is it possible to change the ES_MULTILINE style at runtime? SetWindowLong doesn't seem to be working (once the control had been already created). It doesn't seem right that you can only choose the single or multi line style when you first create the control with CreateWindowEx and then it's set in stone...

No, you cannot change that style; go for ES_MULTILINE right from the beginning. However, you can change the word wrap behaviour:

SendMessage(hRichEd, EM_SETTARGETDEVICE, 0, 1) where lParam=0 means wrap text, 1=don't wrap.

Yes, very nice tip about EM_SETTARGETDEVICE, wouldn't have guessed that from its description... Another thing I wanted to ask is that although I've created the RichEdit control with the WS_TABSTOP style, it seems to skip right past it to the next control on the form whenever I press TAB.

I've tried changing its ZOrder with SetWindowPos but to no avail. It seems that TAB works only for those controls which are present in the form's Controls collection. I've tried adding the RichEdit to the controls collection (Form.Controls.Add) but that requires the ProgID of the control and RichEdit doesn't seem to have a ProgID (although it does have an IID).

Is there any way to make TAB switch the focus to RichEdit controls short of hooking keyboard input and watching for VK_TAB?

Quote:

---

Originally Posted by VanGoghGaming

Is there any way to make TAB switch the focus to RichEdit controls short of hooking keyboard input and watching for VK_TAB?

---

Yes, just wrap it in an ActiveX control and site it on the form the proper way, not by creating child hWnds with API calls.

Then, you would need to implement IPAO which is not simple too but can peek in Krool's controls replacement effort or this sample on PSC.

cheers,
</wqw>

It's funny that I've read your post just as I finished placing the RichEdit control in a PictureBox container (created dynamically on the main form). This seems to be a much simpler solution than wrapping it in an ActiveX control...

Now the PictureBox container catches "Tab" via its "GotFocus" event and elegantly calls "SetFocus" on the RichEdit control!

Quote:

---

Originally Posted by VanGoghGaming

It's funny that I've read your post just as I finished placing the RichEdit control in a PictureBox container (created dynamically on the main form). This seems to be a much simpler solution than wrapping it in an ActiveX control...

Now the PictureBox container catches "Tab" via its "GotFocus" event and elegantly calls "SetFocus" on the RichEdit control!

---

Yes.... I had tried this before, but I used a usercontrol, as wqweto said....


Edit: I actually used a picturebox inside the usercontrol.... until I used IPAO to get around this... and removed the picturebox.

Yeah I have glanced over this IPAO thing but it looks ridiculously convoluted to implement (mostly because I don't have experience with these OLE interfaces)! :D On the other hand, the PictureBox method seems to provide mostly the same functionality, although probably not approved by puritans, haha!

I have uploaded this PictureBox implementation of RichEdit controls in the CodeBank for anyone interested:
VB6 RichEdit (riched20.dll) lightweight Unicode Textbox (only code, no OCX required)

Quote:

---

Originally Posted by VanGoghGaming

although probably not approved by puritans, haha![/url])

---

The issue is not purity .... but dribbling and obstacle .... I removed the IPAO several times, but due to certain problems I had to implement them.

Can you believe it.... VBAcellerator, Krool's controls, etc, had to implement them.

It would help if you could elaborate on what kind of problems forced you to implement IPAO. I guess it ultimately boils down to the complexity of your projects and the expectations of your users (assuming you don't code for yourself in which case the expectations are much closer to reality rather than fantasy, haha).

Quote:

---

Originally Posted by VanGoghGaming

It would help if you could elaborate on what kind of problems forced you to implement IPAO. I guess it ultimately boils down to the complexity of your projects and the expectations of your users (assuming you don't code for yourself in which case the expectations are much closer to reality rather than fantasy, haha).

---

I had problems with SetFocus ..... but in this case in a RichEdit installed in a usercontrol .... but you used it in a Form. In this case, I don't know if there is discrepancy.

Yes I develop for myself LOL

Forgiveness, a thousand pardons...

You mean msftedit.dll ..... I mean riched20.dll v5 below ..

No, I don't mean msftedit.dll, that's what the OP was talking about. We just highjacked his thread! Anyway there is no difference between msftedit.dll and riched20.dll in this regard, they both need a PictureBox container! And yes there was a little annoyance with SetFocus but it was solved rather easily if you look at the code I posted in the CodeBank thread...

Quote:

---

Originally Posted by VanGoghGaming

Yes, very nice tip about EM_SETTARGETDEVICE, wouldn't have guessed that from its description...

---

Indeed, it's practically undocumented.

Quote:

---

Is there any way to make TAB switch the focus to RichEdit controls short of hooking keyboard input and watching for VK_TAB?

---

My solution is to subclass RichEdit and normal edit controls to intercept WM_CHAR messages, and use SetFocus. You need a table of handles filled at WM_CREATE, but it's really straightforward.

"WM_CHAR" is not triggered when "Tab" is pressed. I have already solved the focus problem by using a PictureBox container for the newly created RichEdit. This has the added benefit of providing other useful properties that are missing from the RichEdit control (such as the "Font" object) and so the RichEdit can borrow them (see the CodeBank link in post #8 above)!