richedit: Store richedit version rather than boolean bEmulateVersion10 value.

[Chris Ahrendt]

Dylan Smith wrote:
> Currently msftedit.dll is implemented by loading riched20.dll and then 
> riched20.dll registers the classes that msftedit.dll normally register. 
> Native msftedit.dll appears to be a full implementation of the richedit 
> controls, rather than a wrapper.
> 
> Here are the options that I can think of:
> 1. We could continue to implement msftedit.dll as a wrapper around 
> riched20.dll.  This patch would be a step in that direction.
> 2. We could have two separate implementations, despite the fact that the 
> two dlls are very similar.
> 3. We could have one implementation, and hope that it doesn't matter to 
> programs using them, but this seem too inflexible to me.
> 4. We could also have a single implementation with preprocessor 
> conditions, and then compile the code twice with different defines.
> 
> On Fri, Jun 27, 2008 at 3:30 PM, Phil Krylov <phil.krylov at gmail.com 
> <mailto:phil.krylov at gmail.com>> wrote:
> 
>     Hi,
> 
>     2008/6/27 Dylan Smith <dylan.ah.smith at gmail.com
>     <mailto:dylan.ah.smith at gmail.com>>:
>      > riched20.dll is implementing all the versions of richedit
>     controls (1.0, 2.0,
>      > 3.0, and 4.1), so it is better to store the version that is being
>     emulated.
>      > The bEmulateVersion10 value is replaced with dwEmulatedVersion.
> 
>     I thought it implements 1.0 emulation for riched32.dll usage and
>     latest possible version for other usages - just like native. Or are
>     you planning to add some functionality depending on the actual
>     emulated version, not on (dwEmulatedVersion < 0x200) boolean flag?
> 
>     -- Ph.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 
The new guy votes for option one as it gives you the most flexibility 
going forward. 2 -4 have various issues:

Code maintainability. Of course you could extract the common stuff out 
and link it all together but in that case your kind of implementing 
solution one.

Never say never =) and I would bet that it would in the end matter.. and 
your right.. it is very inflexible.

Four kinda sounds kludgy.. While it solves  problem 2 and 3 it seems a 
little inflexible. In this case either one or four are I think the best 
bets with number 1 being the most flexible.