Re: richedit: Store richedit version rather than boolean bEmulateVersion10 value.
Hi, 2008/6/27 Dylan Smith <dylan.ah.smith(a)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.
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(a)gmail.com> wrote:
Hi,
2008/6/27 Dylan Smith <dylan.ah.smith(a)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.
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(a)gmail.com <mailto:phil.krylov(a)gmail.com>> wrote:
Hi,
2008/6/27 Dylan Smith <dylan.ah.smith(a)gmail.com <mailto:dylan.ah.smith(a)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.
2008/6/27 Dylan Smith <dylan.ah.smith(a)gmail.com>:
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.
Of course this looks most sane. But I'm asking if you're going to make use of the dwEmulatedVersion other than "< 0x200"? That is, under what circumstances we should emulate version 2 or 3 when we have support for version 5? It's interesting to me, because it seemed to me that the native versions (starting with 2.0) are very compatible to each other. -- Ph.
On Sun, Jun 29, 2008 at 4:20 AM, Phil Krylov <phil.krylov(a)gmail.com> wrote:
Of course this looks most sane. But I'm asking if you're going to make use of the dwEmulatedVersion other than "< 0x200"? That is, under what circumstances we should emulate version 2 or 3 when we have support for version 5? It's interesting to me, because it seemed to me that the native versions (starting with 2.0) are very compatible to each other.
-- Ph.
I know that versions 2 and 3 are very compatible with, since they register the same class and dll name. Richedit 4.1 however uses msftedit.dll instead, which means that programs would need to explicitlydecide which version they are using depending on which dll they load and which class they specify. Certainly there are differences between richedit 3 and 4.1, but I don't know if programs would depend on these differences.
On 29/06/2008, Dylan Smith <dylan.ah.smith(a)gmail.com> wrote:
On Sun, Jun 29, 2008 at 4:20 AM, Phil Krylov <phil.krylov(a)gmail.com> wrote:
Of course this looks most sane. But I'm asking if you're going to make use of the dwEmulatedVersion other than "< 0x200"? That is, under what circumstances we should emulate version 2 or 3 when we have support for version 5? It's interesting to me, because it seemed to me that the native versions (starting with 2.0) are very compatible to each other.
-- Ph.
I know that versions 2 and 3 are very compatible with, since they register the same class and dll name. Richedit 4.1 however uses msftedit.dll instead, which means that programs would need to explicitlydecide which version they are using depending on which dll they load and which class they specify.
Certainly there are differences between richedit 3 and 4.1, but I don't know if programs would depend on these differences.
OK I see your point, and after hitting a very interesting blog on RichEdit, I even agree that the exact version number may be needed. http://blogs.msdn.com/murrays/archive/2006/10/14/richedit-versions.aspx http://blogs.msdn.com/murrays/archive/2006/10/20/some-richedit-history.aspx BTW they say that the DLL name for versions 5.0, 5.1, and 6.0 is riched20.dll again. -- Ph.
participants (3)
-
Chris Ahrendt -
Dylan Smith -
Phil Krylov