On Fri, Feb 27, 2009 at 3:02 PM, Dylan Smith
<dylan.ah.smith(a)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:
1. msftedit currently uses the native version by default
2. 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