Hi Michael,
This isn't quite clear to me. It sounds like you are saying there is a riched20.dll in wine, but I can't find one.
No, there's no riched20.dll implementation in Wine as yet.
Are these statements correct?
- Wine's only implements RichEdit10A via riched32.dll. Wine does not
implement RichEdit20A.
Right.
- Win2K (and later) provides riched20.dll which implements
RICHEDIT_CLASS20A. This one I can verify as true on my winxp system.
Right.
- There are significant differences between the two window classes
RICHEDIT_CLASS20A extends RichEdit10A ... so it supercedes it.
My winelib app is hosting a 3rd party DLL which is specifically requesting "RichEdit20A". That suggests that the DLL was built with win2K or later, from what you were saying. Sounds like my options are to:
- hack their request to use the window class registered by wine's
riched32.dll. How well could I expect this to work? How big are the diffs between 10A and 20A?
I think that would probably work.
- get them to provide win2k's riched20.dll
My preference is always to fix Wine...
- have them change their DLL to ask for RichEdit10A instead
Yes, that would work.
- implement riched20.dll in Wine. Sounds like a big job!
Yes, it's a big job, but once the correct skeleton is in place, people will extend it.
Sound right? Any comments? Thanks a bunch... mo
We have an empty implementation of riched20 that simply forwards requests to edit. That is the wrong, and the existing riched32 code is broken too (since it uses the edit control).
CrossOver's riched20 code is attached... it's a quick and easy way to fix the problem, but the correct, longterm solution for Wine is to implement riched20.dll properly and then forward requests from riched32 to riched20 rather than the edit control, which is why this code is not in WineHQ.
It depends how nice you want it to look...
Mike