Prev: Heap stack Class questons
Next: Format of the What's This Popup Help Text file
From: David Webber on 3 Jun 2010 12:06


"David Ching" <dc(a)remove-this.dcsoft.com> wrote in message
news:7874DED8-2B21-4AB5-A0EF-A9362F1AE9D0(a)microsoft.com...
> "David Webber" <dave(a)musical-dot-demon-dot-co.uk> wrote in message
> news:uQeA$lxALHA.1892(a)TK2MSFTNGP05.phx.gbl...
>>
>
> Glad you got it working! :-)
>
>> I now have written out 1000 times:
>>
>> "When creating a new MFC solution and importing old code, check very
>> carefully ALL the functions which the App Wizard provides for you!
>> Especially DllMain!"
>>
>
> Did you use Copy/Paste? ;)

Not as such for the code which the AppWizard created. The AppWizard code is
sufficiently different for the stuff I've done now from my original, that
I'm stepping around it very gingerly. There's history in there.

Version 1 of my music notation software, Mozart, was written using Borland
C++ between roughly 1991 and 1994. It was C++, but only used the raw
Windows API - no framework classes. (It existed before that on an Atari 520
in pure C, but the machine proved not to be up to the job!)

No sooner was it finished, than Windows 95 came out, and I had the task of
making all my 16bit WPARAMs into 32bit and fixing the messaging and all that
(remember those days? <g>) and it looked - well fiddly. But nice Mr Gates
had an upgrade path for MFC programs - which involved no manual work :-)
So in 1995 I bought the then copy of Visual Studio (or whatever it was
called in those days) and rewrote the program as a 16 bit MFC app, and then
pressed the button to get a 32bit MFC app. So my original framework was
created with an MFC AppWizard which is so old that even museums probably
can't find copies. Since then it has evolved, getting more modern things
bolted on. But in those days there was CWinApp and not CWinAppEx, etc etc
so I'm stepping carefully round the AppWizard code.

At one stage I had the idea to separate the drawing code from the program
interface, so I had indirect inheritance, broadly:


CMyApp - CMusApp - CWinApp
CMainFrame - CMusFrame - CMDIFrameWnd
CMyView - CMusView - CView
CMyDoc - CMusDoc - CDocument

with the intermediate classes in a separate MFC extension DLL holding data
common to a number of executables. All the drawing code is in that DLL.
All the document data is held in CMusDoc in that DLL and so on.

Two executables use this hierarchy: my music editor and the free viewer for
its files. The top level objects, eg CMyApp, are different, but the
drawing code in the intermediate DLL is the same.

It was recreating that DLL with the App Wizard (as it was the most probable
source of my problems), I had to replace the dependencies by CWinAppEx and
CMDIFrameWndEx before doing anything else. Now I am gradually importing
code. But it seems I don't need it all. For example the new hierarchy
seems to have GDI+ functionality, whereas previously I had to explicitly
initialise it and tidy it myself. Not sure yet.

Basically I'm keeping all all the InitInstance() stuff at the other end of a
long barge pole, and trying to introduce my own initialisation in the right
places. I completely overlooked the new DllMain() !!!!

Also, as I go along, I'm trying to restructure things so that next time I
have to do this, it will be easier. Maybe I shouldn't have waited 15 years
:-)

>> Now if there was something like
>>
>> #define UNINITIALISED_VARIABLE 0xcccccccc
>> ...

> So it wouldn't have helped to check for UNINITIALISED_VARIABLE anyway.

Probably not.

But I'm still old fashioned enough to use ::IsWindow() at crucial points to
check HWNDs, and something similar for HINSTANCEs *would* have been nice.
:-)

Dave
--
David Webber
Mozart Music Software
http://www.mozart.co.uk
For discussion and support see
http://www.mozart.co.uk/mozartists/mailinglist.htm





First  |  Prev  | 
Pages: 1 2 3
Prev: Heap stack Class questons
Next: Format of the What's This Popup Help Text file