Dan Kegel wrote:
On Fri, Feb 27, 2009 at 3:02 PM, Dylan Smith dylan.ah.smith@gmail.com wrote:
Say, have we considered making riched20 prefer native? That makes the app work, too.
A couple of things to note, in case they are relevant:
- msftedit currently uses the native version by default
- builtin msftedit will not work with native riched20, since the classes
native msftedit loads are instead loaded by builtin riched20, and msftedit just loads riched20
Hmm. So making riched20 prefer native would break apps that use msftedit, if native riched20 but no native msftedit is present?
Does this mean that our msftedit is doing things differently than the native one?
Let's stick a fork in this conversation for a moment and think about what we are saying here:
Office 2007 comes with an 'improved' richedit handing set of files, riched20.dll and riched32.dll which function drastically different from those supplied with WindowsXP and even possibly Vista.
So what do we do?
1. Detect and use the native dlls for Office2007 and use ours for everything else (or) 2. Work on blackboxing those dlls and adding in those functions that are not currenly supported into the native dlls?
I prefer the second solution as this gets rid of 'dll hell' and makes our dlls implementations better than those of MicroSoft.
Opinions from those gathered around the soapbox?
James McKenzie