Partilhar via


ATL e MFC alterações: 7,0 ATL e MFC 7,0

Observação:   Alguns recursos mencionados neste tópico talvez ainda não existem na versão corrente do Visual C++

Muitos aprimoramentos foram feitos bibliotecas ATL e MFC desde o Visual C++ 6.0.Algumas dessas alterações poderá dividir o código existente.

Incompatibilidades DLL

sistema autônomo arquivos do ATL e MFC DLL de entrega sistema autônomo parte do Visual C++ .NET 2002 foram renomeados para ATL70.dll e MFC70.dll, respectivamente.

As classes do Visual C++ .NET ATL e MFC não são binário compatível com as mesmas classes de versões anteriores e, portanto, qualquer código-fonte criado usando mfc42.dll deve ser reconstruído com o Visual Studio .NET.Quaisquer arquivos DLL ou LIB usados pelo seu aplicativo também devem ser recriados com o Visual Studio .NET.

Por exemplo, uma biblioteca que contém uma função exportada levando CString sistema autônomo um parâmetro foi criado usando o Visual C++ 6.0 dará externo não resolvido durante a vinculação com um projeto Visual C++.NET.

Classes de módulo do ATL

3.0 ATL fornecidos a classe CComModule. No 7.0 ATL, a funcionalidade anteriormente fornecida por CComModule é tratada por várias classes novas. See Classes de módulo do ATL para obter mais informações.

Conversões de seqüência de caracteres

Nas versões do ATL até e incluindo 3.0 ATL no Visual C++ 6.0, as conversões de seqüência de caracteres usando as macros no atlconv.h sempre foram realizadas usando a página de código ANSI do sistema (CP_ACP).A partir do 7.0 ATL no Visual C++. NET, conversões de seqüência de caracteres são executadas usando a página de código ANSI padrão do segmento corrente, a menos que _CONVERSION_DONT_USE_THREAD_LOCALE é definida, caso em que a página de código de ANSI do sistema é usada sistema autônomo antes.

Observe que a conversão de seqüência de caracteres de classes, sistema autônomo CW2AEX, permitem que você transmita uma página de código a ser usado para a conversão em seus construtores. Se uma página de código não for especificada, sistema autônomo classes usam a mesma página de código sistema autônomo sistema autônomo macros.

Para obter mais informações, consulte ATL e MFC string conversão macros.

CException agora é uma classe base abstrata

CException é a classe base para todas as exceções na biblioteca Microsoft Foundation Class. Porque CException é agora uma classe base abstrata, não é possível criar CException objetos diretamente; você deve criar objetos de classes derivadas. Se você criar um objeto diretamente, você receberá um erro.Para obter mais informações, consulte CException.

Convertendo BSTR em CString

No Visual C++ 6.0, era aceitável o uso de código a seguir:

BSTR bstr = SysAllocString(L"Hello");
CString str = bstr;
SysFreeString(bstr);

Com novos projetos em Visual C++. NET, isso fará com que o erro a seguir em compilações ANSI:

error C2440: 'initializing' : cannot convert from 'BSTR' to 
'ATL::CStringT<BaseType,StringTraits>'

Agora há versões UNICODE e ANSI de CString (CStringW e CStringA). Para sinalizar qualquer sobrecarga desnecessária incorrida por conversões implícitas, construtores que utilizam o inverso digite (por exemplo, CStringA tirando um argumento UNICODE, ou CStringW Dê um argumento de ANSI) agora são marcadas sistema autônomo explícito usando a seguinte entrada no stdafx.h:

#define _ATL_CSTRING_EXPLICIT_CONSTRUCTORS

Como solução alternativa para esse erro, siga um destes procedimentos:

  • Use CStringW Para evitar a conversão:

    BSTR bstr = SysAllocString(L"Hello");
    CStringW str = bstr;
    SysFreeString(bstr);
    
  • Chame explicitamente o construtor:

    BSTR bstr = SysAllocString(L"Hello");
    CString str = CString(bstr);
    SysFreeString(bstr);
    
  • Remova a linha #define _ATL_CSTRING_EXPLICIT_CONSTRUCTORS de stdafx.h.

CTime alterações

Classe CTime utiliza a base __time64_t tipo de dados. No MFC 6.0, CTime usado o time_t tipo de dados que, em seguida, era um tipo de 32 bit. O motivo para que essa alterar é oferecer suporte a horários além de 3: 14: 07 em 19 de janeiro de 2038.

CComEnumImpl::ignorar alterações

The CComEnumImpl::ignorar método em versões anteriores a ATL 7.0 não retornaria o código de erro correto para um valor de entrada 0.Ele também pode tratar grandes valores de entrada de maneira divergente.Esses comportamentos foram corrigidos no ATL 7.0.

CWnd::DestroyWindow asserções

Quando uma dica de ferramenta foi exibida em CWnd::DestroyWindow, ocorrerá um erro de declaração.sistema autônomo resultado, no MFC 7.0, sistema autônomo seguintes variáveis de membro foram movidas de AFX_THREAD_STATE to AFX_MODULE_THREAD_STATE:

  • M_pToolTip CToolTipCtrl *

  • M_pLastHit CWnd *

  • int m_nLastHit

  • TOOLINFO m_lastInfo

  • int m_nLastStatus

  • M_pLastStatus CControlBar *

LNK2001 Não resolvida external símbolo erro

Ao chamar uma função em uma biblioteca estática ou DLL que leva um wchar_t (Observe que resolvem BSTR e LPWSTR para tipo wchar_t*), você pode obter um LNK2001 unresolved externo erro de símbolo.

Este erro é causado pelo /Zc:wchar_topção do compilador , que é definida como em por padrão em novos projetos MFC.Essa opção faz com que o compilador a tratar wchar_t sistema autônomo um tipo nativo. Antes de Visual C++. NET, wchar_t foi tratado sistema autônomo um unsigned short.

Se o projeto principal e a biblioteca não usam a mesma configuração para /Zc:wchar_t, isso fará com que uma incompatibilidade de assinaturas de função.Para evitar esse problema, recrie a biblioteca com opção do compilador /Zc:wchar_t ou desativá-lo no projeto principal usando o Tratar wchar_t sistema autônomo tipo interno configuração de a linguagem página de propriedades de a Páginas de propriedades caixa de diálogo.

booliano expressões tem agora do tipo bool, BOOL não

Considere a seguinte classe:

class CMyClass : public CObject
{
   BOOL bFlag;

   void Serialize (CArchive& ar))
   {
      if (ar.IsStoring())
         ar << (bFlag != FALSE); // breaking change
      else
         ar >> bFlag;
   }
};

Antes de Visual C++. NET, a expressão bFlag != FALSE avaliado sistema autônomo um BOOL e quatro bytes foram gravados; no Visual C++. NET, ela é avaliada sistema autônomo um bool e é escrito um byte. Isso significa que programas compilados com diferentes versões do compilador podem produzir arquivos de dados mutuamente incompatíveis.

Para evitar o problema, converter a expressão a ser BOOL:

ar << (BOOL)(bFlag != FALSE);

CColorPropPage e CFontPropPage foram removidos

Em versões anteriores do MFC, um controle ActiveX exibido páginas de propriedade para propriedades de cor ou fonte, especificando o GUID CLSID_CColorPropPage or CLSID_CFontPropPage, respectivamente.Esses GUIDs apontada para as classes CColorPropPage and CFontPropPage, que não são implementadas.Em vez disso, use o GUIDs CLSID_StockColorPage and CLSID_StockFontPage.Eles são implementados por msstkprp.dll, para que essa DLL deve ser redistribuir com seu aplicativo.

ON_MESSAGE alterações

O parâmetro de função no ON_MESSAGE macro deve corresponder ao tipo afx_msg LRESULT (CWnd::*)(WPARAM, LPARAM).

Alterações de modelos de BD OLE DB

Você pode encontrar mais informações sistema autônomo alterações nos OLE DB modelos conforme descrito no artigo da Base de dados de Conhecimento da "INFO: Portando problemas com classes de modelo do Visual Studio .NET OLE DB provedor"(Q321743).Você encontrará artigos da Base de dados de Conhecimento no CD-ROM Biblioteca MSDN ou em http://suporte.Microsoft.com/suporte.

OLE DB consumidor classes e modelos

sistema autônomo uma observação geral, a classe de acessador deve implementar membros adicionais.Isso só é necessário se você implementar sua própria classe de acessador manualmente.Se sua classe de acessador deriva de CAccessor, você não precisa fazer isso.

Comportamento antigo

Novo comportamento

CRowset é uma classe.

CRowset é um modelo de classe e usa um parâmetro TAccessor, uma classe de acessador.

CBulkRowset é uma classe.

CBulkRowset é um modelo de classe.

A classe base para CArrayRowset foi um parâmetro de modelo (valor padrão foi CRowset).

CArrayRowset sempre se deriva CBulkRowset.

CDynamicAccessor::GetColumnInfo adotou três parâmetros.

CDynamicAccessor::GetColumnInfo possui um novo formulário que tem um parâmetro adicional, ppStringsBuffer. Usar esse parâmetro elimina um perda de memória.O método antigo é preterido.

Rowseto segundo parâmetro das CAccessorRowset modelo, é uma classe de conjunto de linhas.

TRowset, segundo parâmetro do CAccessorRowset modelo, é um modelo de classe do conjunto de linhas.

Rowseto segundo parâmetro das CTable modelo, é uma classe de conjunto de linhas.

TRowset, segundo parâmetro do CTable modelo, é um modelo de classe do conjunto de linhas.

Rowseto segundo parâmetro das CCommand modelo, é uma classe de conjunto de linhas.

TRowset, segundo parâmetro do CCommand modelo, é um modelo de classe do conjunto de linhas.

DEFINE_COMMAND macro

DEFINE_COMMAND macro está obsoleto. Uso DEFINE_COMMAND_EX em vez disso.

OLE DB provedor Classes e modelos:

A implementação interna de várias interfaces e métodos foi alterado desde o Visual C++ 6.0. Isso pode causar problemas de compatibilidade dependendo se seu aplicativo substitui esses métodos.

Comportamento antigo

Novo comportamento

A implementação do acessador de conjunto de linhas/usada CSimpleMap/CSimpleArray classes. Classes de coleção fornecido pelo usuário tinham de ser CSimpleMap/CSimpleArray compatível.

A implementação do acessador de conjunto de linhas/usa CAtlMap/CAtlArray classes. Classes de coleção fornecido pelo usuário precisam ser CAtlMap/CAtlArray compatível. Além disso, o código que chama métodos essas classes de coleção deve ser revisado quanto existem diferenças significativas entre o CAtl * and CSimple * classes (parâmetros, valores de retorno e assim por diante) que podem resultar em erros de time de execução.

ICommandImpl derivado de ICommand.

ICommandImpl é um modelo que deriva do modelo CommandBase argumento (o padrão é ICommand).

ICommandTextImpl derivado de ICommandImpl < ICommandImpl <T>.

ICommandTextImpl deriva de ICommandImpl < ICommandImpl <T, ICommandText >.Observe que aqui ICommandImpl deriva da ICommandText (não padrão ICommand).

Consulte também

Referência

ATL e MFC alterações