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:
- 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@gmail.com mailto:phil.krylov@gmail.com> wrote:
Hi, 2008/6/27 Dylan Smith <dylan.ah.smith@gmail.com <mailto:dylan.ah.smith@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.