TN011: Usar MFC como parte de uma DLL

Esta anotação descreve DLLs regulares, que permitem que você use a biblioteca MFC como parte de uma biblioteca de vínculo dinâmico (DLL) do Windows. Ele supõe que você esteja familiarizado com DLLs do Windows e como construí-los. Para obter informações sobre a extensão do MFC DLLs, que permitem que você criar extensões para a biblioteca MFC, consulte Versão DLL do MFC.

Interfaces DLL

DLLs normais assumem interfaces entre o aplicativo e a DLL são especificadas em funções de estilo c normais ou classes explicitamente exportados. Interfaces de classe do MFC não podem ser exportados.

Se uma DLL e um aplicativo quiser usar MFC, em seguida, ambos têm uma opção de usar a versão compartilhada das bibliotecas MFC ou ter uma cópia da biblioteca MFC vinculada estaticamente para eles. Nas versões anteriores ao Visual C++ 4.0, as bibliotecas de vínculo estático MFC eram diferentes para aplicativos e as DLLs. Com a atual versão do MFC, o aplicativo e DLL podem tanto usar uma das versões padrão da biblioteca MFC. Não é uma biblioteca separada para DLLs nesta versão (MFC faz a escolha em tempo de execução).

DLLs normais têm várias vantagens:

O aplicativo usando a DLL não tem que usar MFC ou, para que o assunto, ele não tem de ser um aplicativo do Visual C++.
Com regulares DLLs vinculadas estaticamente a MFC, o tamanho da DLL depende apenas dessas rotinas de tempo de execução MFC e c usadas e vinculadas pelo vinculador.
O tamanho do arquivo de DLLs normais que vincular dinamicamente a MFC pode ser muito menor do que regulares DLLs vinculadas estaticamente a MFC, e a economia na memória usando a versão compartilhada do MFC pode ser significativa. No entanto, você deve distribuir o MFCx0. dll de DLLs compartilhadas e MSVCRTx0.DLL (ou arquivos semelhantes) com sua DLL.
Não há nenhum problema com as classes de alteração abaixo de você. Seu design DLL exporta somente essas APIs que você deseja que ele para.
Com regulares DLLs vinculadas estaticamente a MFC, se DLL e o aplicativo usarem MFC, não existem problemas com o aplicativo que querem uma versão diferente do MFC DLL (ou vice-versa). Uma vez que a biblioteca MFC estiver vinculada estaticamente em cada DLL ou EXE, não há nenhuma pergunta sobre qual versão você tem.

Limitações de API

Alguns recursos do MFC não são aplicáveis para a versão DLL, por causa de limitações técnicas ou porque os serviços normalmente são fornecidos pelo aplicativo. Estas limitações estão listadas abaixo:

CWinApp::Enable3dControls
CWinApp::SetDialogBkColor (a cor é ignorada para caixas de mensagem)

Criar sua DLL

Quando a compilação regulares DLLs vinculadas estaticamente a MFC, os símbolos "USRDLL" e "WINDLL" devem ser definidos. Seu código DLL também deve ser compilado com as seguintes opções de compilador:

/ D_WINDLL significa que a compilação é para uma DLL
/ D_USRDLL especifica que você está criando uma DLL regular

Quando a compilação DLLs normais que vincular dinamicamente a MFC, você deve definir os símbolos acima e usar as opções de compilador acima. Adicionalmente, o símbolo "AFXDLL" deve ser definido e seu código DLL deve ser compilado com:

/ /D_AFXDLL Especifica que você está criando uma DLL regular que vincula dinamicamente a MFC

As interfaces (APIs) entre o aplicativo e a DLL devem ser explicitamente exportadas. É recomendável que você definir as interfaces a ser baixa largura de banda, furando a interfaces c sempre que possível. Interfaces c mais directas são mais fáceis de manter do que as classes de C++ mais complexas.

Coloque o APIs em um cabeçalho separado que pode ser incluído por arquivos c e C++ (dessa forma você não vai limitar os clientes DLL para os programadores de C++). Consulte o cabeçalho TRACEAPI.H no MFC Avançado conceitos exemplo DLLTRACE para um exemplo. Para exportar suas funções, insira-as na seção EXPORTS do arquivo de definição de módulo (.DEF) ou incluir dllexport em suas definições de função. Use __declspec(dllimport) para importar essas funções para o cliente executável.

Você deve adicionar a macro AFX_MANAGE_STATE no início de todas as funções exportadas em DLLs normais que vincular dinamicamente a MFC para definir o estado atual do módulo para o para a DLL. Isso é feito adicionando a seguinte linha de código para o início de funções exportadas da DLL:

nbsp; & nbsp;

AFX_MANAGE_STATE (AfxGetStaticModuleState ())

nbsp; & nbsp;

WinMain - > DllMain

A biblioteca MFC define o ponto de entrada de Win32 de DllMain padrão que inicializa o CWinApp derivado objeto como em um aplicativo de MFC normal. Coloque Tudo inicialização DLL-específicos em função de membro InitInstance como em um aplicativo de MFC normal.

Observe que o mecanismo de CWinApp::Run não se aplica a uma DLL, desde que o aplicativo possui a bomba de mensagem principal. Se sua DLL exibe caixas de diálogo sem janela restrita ou tiver uma janela do quadro principal de seu próprio, bomba de mensagem principal do seu aplicativo deve chamar uma rotina de exportado da DLL que chama CWinApp:: PreTranslateMessage.

Consulte o exemplo de DLLTRACE para o uso desta função.

A função de membro ExitInstance de sua CWinApp classe derivada será chamado a partir o MFC fornecido DllMain função antes que a DLL é descarregada.

O que fazer para vinculá-lo todos juntos

Com regulares DLLs vinculadas estaticamente a MFC, você deve vincular sua DLL com esta biblioteca (NAFXCWD.LIB ou NAFXCW.LIB) junto com a versão dos tempos de execução c chamados ' LIBCMT.LIB'. Essas bibliotecas são predefinidas e podem ser instaladas, especificando-os quando você executa a instalação do Visual C++.

Código de exemplo

Por favor, consulte o programa de exemplo MFC Avançado conceitos DLLTRACE para obter um exemplo completo. Isso inclui uma DLL simple chamada ' TRACER.DLL' que implementa os sinalizadores de rastreamento AFX de diálogo (veja técnica nota 7). Ele também tem um aplicativo HELLO simples que chama o DLL para usar a caixa de diálogo.

Várias coisa interessante notar:

Os sinalizadores de compilador da DLL e o aplicativo são muito diferentes.
As linhas de vínculo e.DEF arquivos DLL e o aplicativo também são muito diferentes.
O aplicativo usando a DLL não tem sequer a ser em C++.
A interface entre o aplicativo e a DLL é um "C"-como API e são exportados com TRACER.DEF.

O seguinte extracto de TRACEAPI.H ilustra o que é necessário para uma API que é definida em uma DLL regular que vincula estaticamente a MFC:

# ifdef __cplusplus
extern "C" {
#endifnbsp; / * __cplusplus * /

struct TracerData
{
    BOOL bEnabled;
    UI&NT sinalizadores;
};

BOOL agora EXPORTAR PASCAL PromptTraceFlags (TracerData FAR * lpData);

# ifdef __cplusplus
}
# endif

Neste exemplo, a declaração é colocada entre um Bloquear de 'extern "C" {}' para os usuários do C++. Isso tem várias vantagens. Em primeiro lugar, faz suas APIs de DLL utilizável por aplicativos de cliente não-c + +. Em segundo lugar, ele reduz a sobrecarga DLL desde desconfiguração do nome C++ não será aplicada para o nome exportado. Por último, ele se torna mais fácil adicionar explicitamente a um.DEF arquivo (para exportação por ordinal) sem ter que se preocupar sobre a desconfiguração do nome.

Todas as funções de API são "Até agora EXPORTAR PASCAL". Embora não estritamente necessárias para DLLs Win32, estas definições foram mantidas volta-migração fácil para Windows de 16 bits. As macros de extremo, PASCALe EXPORTAR todos os expandem para nada em Win32.

As estruturas usadas pela API não são derivadas de classes do MFC e são completamente definidas no cabeçalho da API. Isso reduz a complexidade da interface entre a DLL e o aplicativo e, mais uma vez, torna a DLL utilizável pelos programas em C, bem como.

Qualquer ponteiros de dados usados na API são explícitos FAR ponteiros. Novamente, extremo, não é realmente necessário para Win32, mas é útil se você planeja compilar o código para Windows de 16 bits no futuro.

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

Index