TN019: Atualizando aplicativos MFC existente a MFC 3.0

Esta anotação técnica principalmente fornece diretrizes para migrar aplicativos de MFC 1.0 para MFC 2.0 ferramentas. Adicionais diferenças entre MFC 2.0, 2.5 e 3.0 são apresentadas na primeira seção, a seguir.

Alterações MFC 4.0/3.0 API

Não há alterações conhecidas as APIs do MFC documentados que possam causar código existente exigir mudanças. Há, naturalmente, muitos recursos adicionais que você pode querer aproveitar. Para obter mais informações sobre esses recursos, consulte o Guia do programador do Visual C++.

Alterações MFC 2.5 API

MFC 2.5 adicionou duas características principais para a biblioteca de classes: suporte OLE 2.0, que substituiu o OLE 1.0 suporte e o suporte ODBC que fornece acesso de banco de dados. É a intenção da presente nota técnica para cobrir as alterações de API que podem afetar seu código existente. Para obter informações sobre esses novos recursos, não abrangidas na presente nota técnica, consulte o Guia do programador do Visual C++.

CFrameWnd:: RecalcLayout tem um parâmetro adicional, BOOL bNotify. Isto especifica se ou não a notificar quaisquer servidores OLE que eles layout tem alterado. É normalmente verdadeiro e, portanto, que é o padrão. Essa função é virtual, portanto, se seu programa fornece uma Substituir desta função será necessário adicionar o parâmetro extra para sua função, bem como.

Houve outras alterações a funções não documentadas nas bibliotecas MFC 2.5 para oferecer suporte a OLE 2.0, bem como ODBC. Se seu programa usa APIs indocumentados do MFC, você deve examinar todas essas utilizações para se certificar de que eles ainda são válidos.

Migrar MFC 1.0 aplicativos para MFC 2.0

IMPORTANTE: Para compreender e avaliar as duas abordagens apresentadas abaixo, você deve estar familiarizado com os conceitos do MFC 2.0, tais como as ferramentas e a arquitetura de documento e o Exibir. Sugerimos que você pelo menos trabalhar através do exemplo MFC Tutorial SCRIBBLE em tutoriais antes de iniciar qualquer migração de código existente.

Há duas abordagens básicas para migrar aplicativos existentes do MFC versão 1, lançadas com o Microsoft C7, a MFC versão 2.

Migração mínima

Usando o método de "Mínimos migração", você faz apenas mudanças mínimas necessárias, para que:

• Seu aplicativo MFC 1.0 compila e vincula com êxito com as bibliotecas MFC 2.0.
  
  
• Seus recursos podem ser editados com sucesso usando o Visual C++.
  
  
• Suas funções de manipulador de mensagem e caixa de diálogo dados são reconhecidos pelo ClassWizard.

Esta é a abordagem mais fácil, mas ele não aproveita completamente os recursos ricos na biblioteca MFC 2.0. Mesmo se você escolheu o método de "Migração completa", você precisará compreender e exercer técnicas para migração mínima.

Migração completa

Se você executar uma migração de"cheio", você pode aproveitar totalmente da biblioteca MFC 2.0. Usando o método de migração mínima, você será capaz de editar seu aplicativo usando Visual C++ e ClassWizard. Usando o método de migração completa, você ganha o seguinte suporte a MFC 2.0:

• Arquivo menu e diálogo usuário interfaces padrão. Você conseguir recursos tais como padrão de arquivo abrir e salvar os diálogos, Gerenciador de arquivos, arrastar-e-soltar, most-recently-used interface de menu arquivo e assim por diante.
  
  
• Impressão. Você fornecer o código de exibição; a biblioteca cuida de obter a impressora DC, colocando-se a anulação de diálogo, executando o loop de impressão e assim por diante.
  
  
• Visualização de impressão. Geralmente, você terá que não fazer nenhuma codificação extra para obter a funcionalidade de visualização de impressão em seu aplicativo.
  
  
• Barras de ferramentas e barras de status. Eles agora são fáceis de adicionar ao seu aplicativo usando Visual C++ e MFC 2.0.
  
  
• Divisão windows. Se você estruturar seu código de exibição em classes de modo de exibição, em seguida, você poderá exibi-los no separador windows muito pouco custo adicional.
  
  
• Suporte de OLE2. Utilizando a arquitetura de "Documento/Exibir" seu aplicativo provavelmente pode ser OLE ativado sem uma quantidade significativa de trabalho.

O método de migração global completa é basicamente emular developing an aplicativo MFC 2.0 do zero, começando com AppWizard. A diferença de desenvolvimento de um aplicativo de MFC 2.0 do zero, é claro, que você irá emprestar tanto do código MFC 1.0 que você escreveu faz sentido.

Migração mínima

As subseções a seguir apresentam orientações pormenorizadas para a execução de uma migração de mínima.

Em conformidade com Windows 3.1 ESTRITO typedefs

O padrão baseia-se do 2.0 MFC biblioteca aderir para o Windows 3.1 STRICT typedefs que é explicado no Windows 3.1 SDK. MFC 1.0 tinha STRICT desativado, mas agora MFC 2.0 tem STRICT desativado por padrão. Isso segue o compromisso do MFC para controlar o indústria padrão Windows API e promover práticas de desenvolvimento que facilitar o desenvolvimento de aplicativos robustos mais fácil. Assim como o typedefs STRICT foram úteis para os desenvolvedores das classes MFC 2.0 para produzir software robusto, então isso será verdadeiro para você no desenvolvimento de seu código de aplicativo.

Ao usar o tipo ESTRITO controlo pela primeira vez, muitos erros de compilação resultará normalmente. Modificar seu aplicativo de MFC 1.0 para estar em conformidade com o Windows 3.1 STRICT typedefs pode muito bem representar a maior parte do seu esforço de migração mínima.

Depois que seu aplicativo está em conformidade com a rigorosa, você pode ser capaz de compilar um executável sem mais alterações. Por exemplo, as amostras de ABOUT2 e FILEVIEW MFC 1.0 compilar sem alterações adicionais. Eles já estavam STRICT compatível e fez não usado qualquer alterado APIs do MFC.

Alterações MFC 2.0 API

Além de nos termos do ESTRITO, a maior parte do esforço de fazer uma migração mínima é identificar e alterar seu código de aplicativo de acordo com as relativamente poucas alterações MFC 2.0 API.

De mais de 1800 MFC 1.0 APIs, apenas 20 das APIs que foram alteradas resultam em erros de tempo de compilar. Estas alterações requerem apenas modificações triviais para aplicativos do MFC 1.0 existentes. As alterações mais extensas são a reestruturação arquitetônica das classes OLE. Essas alterações são abordadas em técnicas de observação de 18.

Para antecipar quais alterações você precisará fazer, consulte a secção "Alterações de API alfabética" no final da presente nota técnica. Ele fornece um resumo útil e breve do que MFC 1.0 APIs foram modificados no MFC 2.0.

Se você não faça todas as alterações necessárias para lidar com código MFC 2.0, você receberá várias compilação e vinculação erros. Esses erros são quase sempre fáceis de diagnosticar. Para auxiliar o diagnóstico, nós fornecemos algumas diretrizes na seção "Erros de compilador" no final da presente nota técnica.

Foram removidas as seguintes APIs do MFC no MFC 2.0. Recomendamos APIs alternativo, se for caso disso. Esta lista não inclui alterações não documentada implementação APIs.

CDC::GetDCOrg

GetDCOrg não está disponível no Win32. Para aplicativos do Windows 3. x somente, apenas chamar a API do Windows :: GetDCOrg diretamente.

CRuntimeClass::m_pszClassName

Essa variável de membro é agora um LPSTR ao invés do modelo de memória-dependente (char *). Ele é denominado m_lpszClassName no MFC 2.0.

CMDIChildWnd::m_pMDIFrameWnd

No MFC 1.0, essa variável de membro apontado pai de MDIFrame da classe. Essa variável de membro foi substituído com uma função de membro CMDIChildWnd::GetMDIFrame. Se você estiver usando a interface de documentos múltiplos (MDI) no MFC 2.0, a maioria dos usos CMDIChildWnd::m_pMDIFrameWnd (ou GetMDIFrame) não são mais necessários uma vez que o suporte MDI padrão manipula todos os comandos de menu padrão do Windows MDI.

CFrameWnd::GetChildFrame

Em vez disso, use CMDIFrameWnd::MDIGetActive para quadros MDI.

A seguinte API foi deixada no MFC 2.0 para oferecer suporte a 1 compatibilidade mas está obsoleta. Ele será removido de futuras versões do MFC.

CMDIFrameWnd::CreateClient

Esta funcionalidade foi substituída pelo mecanismo OnCreateClient mais geral que oferece suporte à criação de exibir e o suporte aprimorado de MDI do MFC 2.0. O original CreateClient ainda pode ser usado para aplicativos MDI que gerencia a barra de menu do sua própria janela do quadro MDI (usando CMDIFrame::MDISetMenu). O suporte MDI do MFC 2.0 será automaticamente alternar barra de menus da janela do quadro MDI ao menu para a janela de filho MDI ativo no momento.

Outras alterações relacionadas com a API

Duas classes do MFC de passaram a Afxwin. h no arquivo de cabeçalho AFXEXT:

• CBitmapButton
  
  
• CMetaFileDC

Em seus arquivos. cpp que fazem referência a essas classes, adicionar o seguinte:

# include lt;afxext.h>

Muitas APIs foram alteradas para que eles sejam mais rigorosos sobre o uso do modificador 'const'. Essas alterações resultam em um uso mais consistente do nome do tipo LPCSTR e o novo nome de tipo de Operador LPCRECT. Note que não há nenhum problema de tempo de compilar com estas alterações, uma vez que qualquer tipo pode ser promovido para uma versão const deste tipo quando usado como um argumento. Como a mudança de ESTRITO , isso leva a um código mais robusto, quando seu código usa ponteiros de dados const.

As janela criar funções listadas abaixo agora têm um parâmetro adicional, mas desde que o último parâmetro tem um valor padrão de NULL, código existente funcionará sem modificação. Essas funções são

• CWnd:: Create
  
  
• CFrameWnd::Create
  
  
• CMDIFrameWnd::Create
  
  
• CMDIChildWnd::Create

As funções a seguir foram virtuais no MFC 1.0, mas agora são nonvirtual no MFC 2.0:

• CFile:: GetStatus
  
  
• CFrameWnd::GetParentFrame

Se uma classe derivada de seu aplicativo de MFC 1.0 substitui qualquer uma dessas funções, é improvável que a função em sua classe derivada será chamada no MFC 2.0. Além disso, GetParentFrame foi movido de CFrameWnd para CWnd para ser uma API mais geralmente útil.

Todos os membros estáticos de classes, bem como funções de operador/amigo global, agora cumprir PASCAL convenções de chamada. Todas as funções globais são AFXAPI (PASCAL). Novamente, isto não é uma questão de tempo de compilar, mas gera código mais rápido e menor gerado.

Muitas das classes somente implementação e estruturas foram renomeadas para não usar o prefixo "C". Por exemplo, CExceptionContext foi renomeado para AFX_EXCEPTION_CONTEXT. Essas classes não são documentados e permanecem detalhes de implementação da biblioteca de classes. É improvável que você têm contado com estas, e geralmente, é recomendável que você não confiar em APIs indocumentados da biblioteca de classes uma vez que estão sujeitos a alterações em versões futuras.

Alterações no comportamento padrão de MFC 2.0

Lidar com mudanças na API do MFC é fácil com a ajuda de erros reportados pelo compilador e vinculador. Nem todas as alterações de biblioteca são reveladas nos arquivos de cabeçalho de biblioteca, no entanto. Algumas alterações são reveladas no comportamento de tempo de execução do seu aplicativo. Essas alterações geralmente não são difíceis de lidar, enquanto você antecipá-los. As seguintes informações são fornecidas para ajudá-lo a antecipar essas mudanças comportamentais.

CDialog e CModalDialog foram fundidos em uma única classe. CModalDialog é agora considerada uma classe obsoleta. No entanto, para compatibilidade de MFC 1.0, todas as referências a CModalDialog são ainda válidas através de uma macro de migração em Afxwin. h:

# define CModalDialog CDialog

Para muitos aplicativos MFC 1.0, este simples # define é suficiente. No entanto, existem casos onde este # define não é suficiente.

Se você implementou uma caixa de diálogo sem janela restrita e invocado o comportamento padrão de "não fazer nada" para OnOK e OnCancel, em seguida, você deve substituir estas e o comportamento padrão, pois eles agora chamam EndDialog (para processamento de caixa de diálogo modal).

CDialog::CreateIndirect ainda cria uma caixa de diálogo sem janela restrita. Para criar uma caixa de diálogo modal usar CDialog::InitModalIndirect em vez de removidos CModalDialog::CreateIndirect API.

Cores de fundo caixa e mensagem caixa diálogo podem agora ser globalmente definidas usando o CWinApp::SetDialogBkColor API. O parâmetro padrão define a cor para cinza claro (não COLOR_BTNFACE) para produzir planos de fundo cinzas. Você pode especificar outras cores.

Se SetDialogBkColor não é chamado no seu CWinApp-derivado InitInstance função, o padrão de fundo da janela cor (definida no miniaplicativo cor de painel de controle) é usado.

No MFC 1.0, se um DLL contido um objeto CWinApp , foi necessário estabelecer um DllMain que incluiu uma chamada para AfxWinTerm. MFC 2.0 fornece esta DllMain, assim, qualquer código adicional incluído no seu DllMain deverão ser migrados para função de membro cWinApp::ExitInstance da DLL.

CMDIChildWnd::Create agora corretamente usa o parâmetro dwStyle . Agora você deve especificar um estilo de janela completa para a janela filho MDI. Se você especificar dwStyle = 0, agora você vai ter uma falha de declaração em CMDIChildWnd::PreCreateWindow. Para evitar isso, você deve especificar o estilo WS_CHILD | WS_VISIBLE | WS_OVERLAPPEDWINDOW para ser compatível com versões anteriores com o MFC 1.0.

MFC 2.0 suporta definição de estilos diferentes para o filho MDI windows, então você pode remover alguns dos controles de janela do quadro, se desejado.

Classe CFrameWnd tem um novo membro de dados, BOOL CFrameWnd::m_bAutoMenuEnable. Ele é definido como TRUE por padrão. Isso faz com que itens de menu que não têm manipuladores de ON_UPDATE_COMMAND_UI ou ON_COMMAND automaticamente desactivados. Itens de menu que tem ON_COMMAND manipuladores, mas nenhum manipulador ON_UPDATE_COMMAND_UI , serão habilitados automaticamente.

Isso torna mais fácil para implementar comandos opcionais com base na seleção atual. Também, isso reduz bastante a necessidade de aplicativos para gravar ON_UPDATE_COMMAND_UI manipuladores para ativar/desativar itens de menu. Por exemplo, um aplicativo gerados pelo AppWizard terá editar cortar/copiar/colar desabilitado até que o programador implementa manipuladores para eles.

No entanto, se seu aplicativo MFC 1.0 não é atualizado para usar ON_COMMAND e ON_UPDATE_COMMAND_UI manipuladores, então ele deve limpar m_bAutoMenuEnable explicitamente. Caso contrário, menus que você desabilitar vão ser reativados automaticamente.

Alterações de projeto (compilação)

Você pode continuar a desenvolver seu aplicativo de MFC 1.0 usando um makefile padrão. De longe a forma mais fácil de migrar seu projeto é usar o recurso de projeto Visual C++ para manter seu depedencies e outras opções de projeto dentro do ambiente do Visual C++.

Um erro de ligação comum é externals não resolvidos para COMDLG32.DLL e SHELL32.DLL APIs. Certifique-se de vincular com COMDLG32.LIB e SHELL32.LIB.

Você pode ser capaz de melhorar a compilação vezes colocando # incluem lt;afxwin.h > em um cabeçalho pré-compilado. Por Convenção, aplicativos MFC 2.0 especificam "stdafx. h" como o cabeçalho pré-compilado. Em seguida, o módulo stdafx. cpp inclui stdafx. h. Esta técnica é ilustrada pelo código criado por AppWizard e por muitos dos exemplos MFC 2.0.

&Notanbsp;  É importante que você não define nem remover qualquer um das macros AFX_NO_XXX stdafx. h. Consulte o artigo da Base de conhecimento "PRB: problemas ocorrem ao definindo AFX_NO_XXX." Você pode localizar artigos da Base de dados de conhecimento no CD de biblioteca do MSDN ou no http://www.microsoft.com/kb/.

O Visual C++ e ClassWizard compatibilidade

Mesmo para migração mínima, recomendamos que você siga as etapas abaixo para que você pode usar Visual C++ e ClassWizard para editar seus recursos do aplicativo e código.

• Para qualquer módulo cujo mapa de mensagem que deseja editar com ClassWizard, adicionar as seguintes linhas duas comentário no arquivo de. cpp fora de qualquer implementações de função:

  //{{AFX_MSG_MAP (lt; nome da classe >)
  //}}AFX_MSG_MAP
  

  lt; nome da classe > é o nome de sua classe que contém o mapa de mensagem.

  Da mesma forma, adicione as seguintes linhas de dois comentário dentro da declaração da classe correspondente no arquivo. h:

  //{{AFX_MSG (lt; nome da classe >)
  //}}AFX_MSG
  

  Para obter um exemplo destas declarações, Olhe para as mesmas linhas de comentário em qualquer aplicativo criado por AppWizard. Para obter uma explicação sobre o que significam essas linhas de comentário, consulte MFC: usando os arquivos de origem MFC no Guia do programador do Visual C++.

• Seu projeto deve ter um makefile chamado lt; projeto > portados e um arquivo de recurso chamado <project>. RC, onde <project> é o nome do seu projeto. Ambos esses arquivos devem estar localizados no diretório de raiz do projeto. O.MAK ficheiro pode ser um makefile externo.
  
  
• Execute ClassWizard de dentro de Visual C++. Quando ClassWizard descobre que um.CLW arquivo não existir, ele perguntará se você deseja criar um. Responda 'Sim'. O.CLW é essencialmente um arquivo de índice que ClassWizard utiliza para identificar os módulos que têm tais linhas de comentário //{{AFX_MSG.
  
  
• Para qualquer módulo cujas funções virtuais que você deseja editar com ClassWizard, adicionar as seguintes linhas de duas comentário dentro de sua declaração de classe no arquivo. h:

   //{{AFX_VIRTUAL (lt; nome da classe >)
  //}}AFX_VIRTUAL
  

Migração completa

Uma migração completa do seu aplicativo c ou MFC 1.0 para MFC 2.0 oferece-lhe todas as vantagens do MFC 2.0. Para a maioria dos aplicativos, uma migração completa não é difícil e vale a pena o esforço.

Uma bem-sucedido migração completa de um aplicativo para MFC 2.0 requer essencialmente a mesma compreensão do MFC 2.0 como o desenvolvimento de um novo aplicativo do zero. Você deve se familiarizar com a biblioteca de classes do MFC 2.0, Visual C++, AppWizard e ClassWizard antes de começar a migração completa. Você deve compreender quais partes do seu código do aplicativo podem ser removidos por derivar funcionalidade equivalente ou melhor das classes MFC 2.0. Não só vai usar mais a implementação da biblioteca fazer seu código-fonte menor, mas vai fazer essas partes do seu aplicativo melhor integrada com o restante da estrutura do MFC.

Totalmente Migrando sua aplicação para MFC 2.0, você será capaz de derivar funcionalidade adicional de MFC em relativamente pouco custo extra. Por exemplo, se seu aplicativo não tinha uma interface de usuário de janela de separador, mas um seria útil para os usuários, então você será capaz de rapidamente adicionar esse recurso, já tendo portado o seu código para arquitetura de documento/Exibir do MFC 2.0.

Embora uma migração completa para MFC 2.0 pode exigir esforço um par de dias para aplicativos grandes, o processo em si é bastante simples. As etapas gerais a seguir descrevem o processo de:

1. Analisar como factores de sua arquitetura de aplicativo existentes no documento, modos de exibição e quadro windows.

   Fazer isso antes de começar a editar qualquer código. Muitos programadores tendem a se entrelaçam código do documento com o código de modo de exibição. Embora fazer assim não é necessariamente "mau", separação de funcionalidade de documento e o Exibir é uma filosofia de design que a estrutura do MFC aprova e apoia particularmente bem. Apesar de MFC 1.0 não tem classes de CDocument , CView , também subscreveu separação de documento/Exibir. Assim que todas as futuras versões da biblioteca.

   Estudar os exemplos MFC 2.0 que usam as classes CDocument e CView , particularmente o MFC exemplo Tutorial Rabisco. Em seguida, analise o aplicativo para determinar o que é o documento e o que é o modo de exibição. Determinar se seu aplicativo tiver vários tipos de documentos ou modos de exibição.

   Mesmo se seu aplicativo não se presta a separação de documento/Exibir clara, ainda será capaz de migrar para MFC 2.0 totalmente e aproveitar essencialmente completa do quadro. Você pode "fake" separação de documento/Exibir através da implementação de CDocument- e CView-derivado classes, mas seu documento ou modo de exibição classe pode delegar a maior parte do seu trabalho para a outra classe. Ou, pode recorrer a sua classe de exibir seus CFrameWnd- ou CMDIChildWnd-derivado classe para implementar a maior parte da interface do usuário do seu aplicativo. Em resumo, você tem quase total liberdade quanto à forma de separar seu documento, exibir e classes de janela do quadro.

   Sua análise também deve determinar se seu aplicativo precisar de várias classes de exibir e possivelmente várias classes de documento. Aplicativos ainda relativamente simples, às vezes, precisam mais de uma classe de Exibir. No entanto, vários modos de exibição, como em uma janela separadora, necessariamente não ditam que você tenha vários CView-derivado classes. Por exemplo, se cada painel na janela do divisor oferece a mesma interface de usuário como outros painéis na janela separadora, eles podem compartilhar a mesma classe de Exibir. Nesse caso, cada painel é simplesmente um objeto distinto da mesma classe de modo de exibição. Você provavelmente vai querer criar várias classes de exibição, se seu aplicativo fornece interfaces de usuário muito distintas em janelas diferentes.

2. Analisar quais recursos de quadro suportado pelo AppWizard seu aplicativo precisará.

   AppWizard cria um esqueleto aplicativo MFC 2.0 que oferece suporte a vários recursos do framework que você seleciona como opções nas caixas de diálogo de AppWizard. Antes de executar o AppWizard para criar seu aplicativo esqueleto, você deve primeiro se familiarizar com as opções de que AppWizard fornece.

   Em seguida, tome um pouco de tempo para decidir qual das opções do AppWizard você selecionar. Não tente fazer isso em poucos minutos a primeira vez que você executar o AppWizard. Por exemplo, se seu aplicativo já não oferece suporte a OLE, esta é uma decisão importante que você vai querer considerar. Se você não escolher opção de OLE do AppWizard para começar com, você ainda será capaz de modificar o código do seu aplicativo para usar os recursos do OLE do MFC. Mas a partir com a opção de OLE em AppWizard para começar com vai poupar tempo.

   Sua análise deve determinar se seu aplicativo é uma interface de documento simples (SDI) ou aplicativo de interface (MDI) documento várias. Essa determinação particular deve ser óbvia se você estiver familiarizado com essas duas interfaces de usuário distinta em outros aplicativos do Windows. AppWizard irá criar aplicativos MDI por padrão desde que a interface do usuário MDI é geralmente mais funcional para os usuários finais para que lhes permite abrir mais de um documento/arquivo de cada vez. Felizmente, com a arquitetura de documento/Exibir do MFC 2.0, suporte MDI não requer nenhuma codificação extra de sua parte.

3. Gerar um novo aplicativo usando AppWizard.

   Tendo feito a análise acima, agora você está pronto para executar o AppWizard para criar o código esqueleto para seu aplicativo.

   Tendo analisado como seu aplicativo se separa em documento, modos de exibição e quadro windows, você deve ter uma boa idéia que nomes dar aos seus módulos e classes correspondentes. Você pode querer atribuir nomes um tanto genéricos, como o exemplo tutorial CScribDoc e CScribView e scribdoc. cpp e scribvw.cpp. No entanto, se seu aplicativo requer várias classes de Exibir, você vai provavelmente querer dar a primeira classe de modo de exibição criado AppWizard um nome mais especializado, como CDataEntryView e CReportView. Consulte a próxima etapa para obter informações adicionais sobre como criar várias classes de documento e o Exibir.

   Tendo antecipado que opções adicionais de AppWizard você deseja, como SDI ou MDI, e OLE, você deve agora ser capaz de selecionar as opções de AppWizard e criar o aplicativo de esqueleto em apenas alguns minutos.

4. Opcionalmente, clonar segundo modo de exibição, documentos e classes de janela do quadro.

   Se sua análise acima determina que seu aplicativo deve ter vários modo de exibição, no documento ou classes de janela do quadro, então é um bom momento para criar o código esqueleto para estas classes de direito depois de executar o AppWizard.

   Você pode criar um código esqueleto para sua exibição adicional, documento e classes de janela do quadro, clonagem daqueles criados por AppWizard. Ou seja, copie os arquivos. cpp e. h, atribuir um novo nome de módulo para o segundo documento ou classe. Em seguida, edite o código esqueleto alterando nomes de classe. Outra alternativa é usar a funcionalidade de adicionar classe do ClassWizard para criar uma nova classe automaticamente os arquivos que você especifica usando os nomes que você especifica. Você já estará familiarizado com a capacidade do ClassWizard para criar novas classes se você seguiu o tutorial do Rabisco.

   Em qualquer caso, no seu CWinApp-derivado InitInstance função classe, você deve registrar objetos de modelo de documento adicional para quaisquer associações que você deseja fazer entre você Múltiplo documento, exibir e classes de janela do quadro.

   Este é também um passo rápido. Você pode adiar essa etapa se não você empenhados em levar vários documentos, exibições ou quadro da janela classes em seu aplicativo.

5. Migrar as partes relevantes do seu código de MFC 1.0 para as classes criadas pelo AppWizard.

   Esta etapa representa a maior parte do trabalho em migrar seu aplicativo de MFC 1.0 para MFC 2.0. Você deve fazer isso incrementalmente. Migre relativamente pequenas partes do seu aplicativo ao mesmo tempo. Como você faz isso, você vai aprender mais detalhes sobre qual funcionalidade do framework fornece que permitirá que você descartar alguns dos seu código de aplicativo do MFC 1.0 antigo.

   Como migrar esses blocos de código, tenha em mente as orientações apresentadas em "Migração mínimo". Muitas dessas orientações se aplicam a migração completa. AppWizard será já ter adicionado as observações //{{AFX_MSG e //{{AFX_MSG_MAP para suas classes de destino de comando (aplicativo, documento, exibir e janela do quadro). Não é necessário para você adicioná-los manualmente sob a abordagem mínima migração. Embora não seja obrigatório, é recomendável que você mova funções de manipulação de mensagem entre o //{{AFX_MSG os comentários aninhados em mapas de mensagem. Além disso, mova as declarações dessas funções (afx_msg) manipulação de mensagens entre os //{{AFX_MSG os comentários nos arquivos de cabeçalho. Isso permitirá que você usar ClassWizard durante todo o resto da life cycle(s) do seu projeto.

   Estas recomendações sobre //{{AFX_MSG comentários também aplicam, talvez em menor grau, a caixas de diálogo. Se você não antecipou a muitas mudanças futuras para uma classe de diálogo fornecida, então ele pode não ser vale a pena o esforço para tornar esse diálogo ClassWizard-ciente. Isso é bom. Naturalmente, nós recomendamos que você criar todas as novas classes de caixa de diálogo usando a opção de adicionar classe do ClassWizard.

   Como migrar um aplicativo MFC 1.0 ou Windows, você pode querer manter a compatibilidade com formatos de arquivo existentes. (O mecanismo de serialização de documento do MFC 2.0 de padrão não pode ser apropriado para seu aplicativo.) Para direcionar CFile escrever e ler chamadas, ou implementar um arquivo de não-com base em documento, você desejará substituir CDocument::OnOpenDocument e OnSaveDocument. O MFC geral exemplo DIBLOOK fornece um exemplo dessa técnica. Se seu aplicativo atual já serializa objetos, então isso não será um problema.

Alterações de API alfabéticos

Para entender as razões para essas alterações, consulte "Razão para alterações" abaixo.

Razões para as alterações:

• Funcionalidade melhorada. A versão 2.0 do MFC desta API fornece a funcionalidade mais ou melhor sobre sua contraparte MFC 1.0.
  
  
• Estrita conformidade. A API 2.0 MFC foi alterada em conformidade com a API do Windows STRICT.
  
  
• Correção const. A API 2.0 MFC foi fixada a aplicar correctamente a palavra-chave 'const' para facilitar programas mais eficientes.
  
  
• Portabilidade de Win32. A API 2.0 MFC foi alterada para reflectir correctamente a API do Win32 que facilita a fácil portabilidade de aplicativos do MFC para Win32.
  
  
• Uso de memória reduzido. A API 2.0 MFC foi mudada para fornecer uma ligação mais eficiente e técnicas de uso de memória que irão resultar em aplicativos menores e uso DGROUP reduzido.
  
  
• Win 3.1 funcionalidade. O MFC 2.0 API foi alterado para refletir corretamente uma alteração de API do Windows 3.1. A API continua a ser compatível com o Windows 3.0, mas opcionais Windows 3.1 apenas os parâmetros estão agora disponíveis.

Erros do compilador

A maioria das alterações para as APIs do MFC 2.0 irá gerar um dos poucos erros do compilador, ou nenhum em todas as conversões de tipo padrão satisfaça o compilador. Os seguintes erros de compilador podem ser gerados durante a compilação de aplicativos MFC 1.0 existentes no MFC 2.0:

Técnico anotações por número |nbsp; &Notas técnicas por categoria