"David Lowndes" <DavidL@example.invalid> wrote in message
news:ur8rj3t88glq161e5vjk8tmkl8pgm76cmr@4ax.com...
A bit (rather than a "whole lot") longer.
No, it *may* take a whole lot longer. It depends on your application -
and what it interfaces with.
If it's a UI with minimal external interfaces, it's a fairly trivial
undertaking (I've done that myself for a few small applications).
However, if it's an application that has extensive character based
interfaces (anything to do with the antiquated Internet or email
standards for example) and you're into having to understand the depths
of the application to know which bits should remain as char and which
bits can be made Unicode.
Ok I admit that e-mail standards will be more complicated - I hadn't
thought of that.
I've started one of those conversions myself
and ended up backing off because it became a major undertaking.
For me, though, the big decision was whether I could afford to drop Win98
support, as Unicode and Win98 was *really* awkward: I didn't want to
recompile the the MFC DLLs in order to be able to use the "Unicode Layer"
for win98.
Just static link with MFC, Unicows works with that - that's what I
use.
Easy for you to say. :-)
With an exe using several MFC DLL's including fairly "intricate" things
like CGeneralView derived from CView in a DLL, and CMyView1, CMyView2,
CMyView3 in three separate exes, all derived from CGeneralView, I think
you'll agree that this is not an option. [CWinApp CMainframe and
CDocument are treated the same way.]
[In a fit of structural excitement some time ago, I decided to put all the
drawing code in CGeneralView in the DLL, and the command interface -
menus, tool bars etc, one level higher in the EXE. It is quite pleasing
on the whole, but it does rule out static linking with MFC, and so it has
delayed my going Unicode until now.]
Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mozartists/mailinglist.htm