The MFC is constantly changing, sometimes breaking older pgms.
With VC.NET 2010 and Windows 7, I have made a whole new set of projects,
updating them from the last one, 2008.

If you are using the 2008 or earlier compilers, then copy the modified
.cpp and .h files from these 2020 project folders, replacing the older
ones in your projects. Modified files will have an early Nov 2013 date
on them.

If the projects use the multitasking option, which is usually
always the case, we now need to call CoInitializeEx in the app
class, after loading the profile setting:
 LoadStdProfileSettings (4);  // activates Most Recent File menu
 CoInitializeEx (NULL, COINIT_MULTITHREADED); // added for multithreading
This change was made to the app classes in:
Pgm03a, Pgm05a, Pgm05b, Pgm06a, Pgm07a, Pgm10a, and Pgm11a

One nice change impacts Pgm02a, Pgm02b, Pgm02c, FrameWin class.
They have now given us a very easy way to install a user font into
a CEdit control: SetFont(). Here's a snippet that shows the change.
I removed the old hfont and made ptrf a class member and then inserted
a bit more coding to delete any before making a new CFont and to delete
them when the app is terminating.

In Pgm02c folder, changes to FrameWin.cpp
void FrameWin::CmEnumFont () {
...
  memcpy (ptrlogfont, &lf, sizeof (LOGFONT));
  // and reinstall current point size
  ptrlogfont->lfHeight = h;
  ptrlogfont->lfWidth = w;
  Invalidate ();
  // construct font copy for the CEdit control
  // changes start here:
  CFont* ptrf = new CFont(); // new
  ptrf->CreateFontIndirect (ptrlogfont);/// changed
  // force the CEdit window to use new font
  ptreditwin->SetFont (ptrf); /// changed
  delete ptrf;
 }

void FrameWin::CmFontChange () {
...
 if (ptrdlg->DoModal () == IDOK) {     // get user font choice
  if (!ptrlogfont) ptrlogfont = new LOGFONT; // 1st time, create LOGFONT
  memcpy (ptrlogfont, &(ptrdlg->m_lf), sizeof (LOGFONT)); // copy user choice
  // changes start here
  CFont* ptrf = new CFont (); /// new
  ptrf->CreateFontIndirect (ptrlogfont); ///changed
  // force the CEdit window to use new font
  ptreditwin->SetFont (ptrf);///changed
 }

In Pgm08b, SalesView.cpp, I discovered that in some situations, the current
db record position gets lost. So in OnMove() at the end of the coding, I
changed the default call to the base class to catch this lost position error
and restart at the beginning of the record set
 try { // current record postion could be lost, so if it fails reset to start
	return CDaoRecordView::OnMove(nIDMoveCommand);
 }
 catch (CDaoException *ptrex) {
    m_pSet->Requery ();              // issue refresh the record set
    return TRUE;
 }
}


In Pgm13a's FTPView.cpp, I changed the default URL that comes up from
Microsoft to Globalscape, since the ms ftp has gone away.

As always, the OCX samples are problematical, since such is an always
evolving platform. Under Win7, the entire process now requires that the OCX
controls be registered on the computer running them. While there is a procedure
to follow if you were making a production OCX and distributing it professionally,
for testing and experimentation, they allow you to manually register the OCX.
The first registers it:
regsvr32 D:\some set\ of folders to get to\pgm15a.ocx

This one unregisters it when you are finished with it
regsvr32 /u D:\some set\ of folders to get to\pgm15a.ocx

So to get Pgm15b to run as it currently is,
register the OCX in one of the folders where Pgm15a's OCX file is located.

If you rebuild it, then the long class IDs can change. In that case, after you
register your new one, you may need to open Pgm15b.rc file in Notepad and
find the Dialog1 entry where it displays the long ID.
Open the Pgm15a.idl file, scroll to the very bottom and find the
//  Class information for StopLightCtrl
Just below that is the new long ID. Copy it and paste it over the ID in Pgm15b.rc
file's ID in use in Dialog1. Save the RC file and build Pgm15b. It should then
work fine.