TN057: lokalizacja składników MFC

Uwaga

Następująca uwaga techniczna nie została zaktualizowana, ponieważ została po raz pierwszy uwzględniona w dokumentacji online. W związku z tym niektóre procedury i tematy mogą być nieaktualne lub nieprawidłowe. Aby uzyskać najnowsze informacje, zaleca się wyszukanie interesującego tematu w indeksie dokumentacji online.

W tej notatce opisano niektóre projekty i procedury, których można użyć do lokalizowania składnika, jeśli jest to aplikacja, kontrolka OLE lub biblioteka DLL korzystająca z MFC.

Omówienie

Istnieją naprawdę dwa problemy, które należy rozwiązać podczas lokalizowania składnika korzystającego z MFC. Najpierw należy zlokalizować własne zasoby — ciągi, okna dialogowe i inne zasoby specyficzne dla danego składnika. Większość składników utworzonych przy użyciu MFC obejmuje również wiele zasobów zdefiniowanych przez MFC i używa ich. Należy również podać zlokalizowane zasoby MFC. Na szczęście kilka języków jest już udostępnianych przez sam MFC.

Ponadto składnik powinien być przygotowany do działania w środowisku docelowym (środowisko europejskie lub z obsługą dbCS). W większości przypadków zależy to od aplikacji traktujące znaki z prawidłowym zestawem bitów i obsługą ciągów z podwójnymi znakami bajtów. MFC jest domyślnie włączona dla obu tych środowisk, tak aby możliwe było posiadanie pojedynczego globalnego pliku binarnego używanego na wszystkich platformach z tylko różnymi zasobami podłączonymi w czasie instalacji.

Lokalizowanie zasobów składnika

Lokalizowanie aplikacji lub biblioteki DLL powinno obejmować po prostu zastąpienie zasobów zasobami zgodnymi z językiem docelowym. W przypadku własnych zasobów jest to stosunkowo proste: edytuj zasoby w edytorze zasobów i skompiluj aplikację. Jeśli kod jest poprawnie napisany, nie będzie żadnych ciągów ani tekstu, które mają zostać zlokalizowane w kodzie źródłowym języka C++ — wszystkie lokalizacje można wykonać po prostu modyfikując zasoby. W rzeczywistości można zaimplementować składnik tak, aby wszystkie udostępniające zlokalizowaną wersję nawet nie obejmowały kompilacji oryginalnego kodu. Jest to bardziej złożone, ale warto i jest mechanizmem wybranym dla samego MFC. Istnieje również możliwość lokalizowania aplikacji przez załadowanie pliku EXE lub DLL do edytora zasobów i bezpośrednie edytowanie zasobów. Chociaż jest to możliwe, wymaga ponownego zastosowania tych zmian za każdym razem, gdy tworzysz nową wersję aplikacji.

Jednym ze sposobów uniknięcia tego jest zlokalizowanie wszystkich zasobów w osobnej biblioteki DLL, czasami nazywanej biblioteką DLL satelitarną. Ta biblioteka DLL jest następnie ładowana dynamicznie w czasie wykonywania, a zasoby są ładowane z tej biblioteki DLL zamiast z modułu głównego ze wszystkim kodem. Usługa MFC bezpośrednio obsługuje to podejście. Rozważmy aplikację o nazwie MYAPP.EXE; może mieć wszystkie swoje zasoby znajdujące się w dll o nazwie MYRES.DLL. W aplikacji InitInstance należy wykonać następujące czynności, aby załadować tę bibliotekę DLL i spowodować załadowanie zasobów z tej lokalizacji przez MFC:

CMyApp::InitInstance()
{
    // one of the first things in the init code
    HINSTANCE hInst = LoadLibrary("myres.dll");

    if (hInst != NULL)
        AfxSetResourceHandle(hInst);

    // other initialization code would follow
    // ...
}

Od tego czasu MFC załaduje zasoby z tej biblioteki DLL zamiast z pliku myapp.exe. Wszystkie zasoby muszą jednak znajdować się w tej biblioteki DLL; MFC nie będzie przeszukiwać wystąpienia aplikacji w wyszukiwaniu danego zasobu. Ta technika jest równie dobrze stosowana do zwykłych bibliotek DLL MFC, a także kontrolek OLE. Program instalacyjny skopiuje odpowiednią wersję biblioteki MYRES.DLL w zależności od ustawień regionalnych zasobu, które użytkownik chciałby.

Stosunkowo łatwo jest utworzyć tylko bibliotekę DLL zasobu. Utworzysz projekt DLL, dodaj element . Plik RC do niego i dodaj niezbędne zasoby. Jeśli masz istniejący projekt, który nie korzysta z tej techniki, możesz skopiować zasoby z tego projektu. Po dodaniu pliku zasobów do projektu jest prawie gotowy do skompilowania projektu. Jedyną rzeczą, którą musisz zrobić, jest ustawienie opcji konsolidatora, aby uwzględnić /NOENTRY. Informuje to konsolidatora, że biblioteka DLL nie ma punktu wejścia — ponieważ nie ma kodu, nie ma punktu wejścia.

Uwaga

Edytor zasobów w programie Visual C++ 4.0 lub nowszym obsługuje wiele języków na . Plik RC. Może to ułatwić zarządzanie lokalizacją w jednym projekcie. Zasoby dla każdego języka są kontrolowane przez dyrektywy preprocesora generowane przez edytor zasobów.

Korzystanie z udostępnionych zasobów zlokalizowanych w MFC

Każda aplikacja MFC, którą tworzysz, używa ponownie dwóch elementów z MFC: kodu i zasobów. Oznacza to, że MFC ma różne komunikaty o błędach, wbudowane okna dialogowe i inne zasoby, które są używane przez klasy MFC. Aby całkowicie zlokalizować aplikację, należy lokalizować nie tylko zasoby aplikacji, ale także zasoby pochodzące bezpośrednio z MFC. MFC udostępnia wiele różnych plików zasobów językowych automatycznie, więc jeśli docelowy język jest jednym z języków, które już obsługuje MFC, wystarczy upewnić się, że używasz tych zlokalizowanych zasobów.

W związku z tym pisaniem MFC obsługuje chiński, niemiecki, hiszpański, francuski, włoski, japoński i koreański. Pliki, które zawierają te zlokalizowane wersje, znajdują się w katalogach MFC\INCLUDE\L.* (L). Na przykład pliki niemieckie znajdują się w MFC\INCLUDE\L.DEU. Aby spowodować, że aplikacja będzie używać tych plików RC zamiast plików znajdujących się w MFC\INCLUDE, dodaj element /IC:\PROGRAM FILES\MICROSOFT VISUAL STUDIO .NET 2003\VC7\MFC\INCLUDE\L.DEU do wiersza polecenia RC (jest to tylko przykład; należy zastąpić wybrane ustawienia regionalne, a także katalog, do którego zainstalowano program Visual C++).

Powyższe instrukcje będą działać, jeśli aplikacja łączy się statycznie z MFC. Większość aplikacji łączy się dynamicznie (ponieważ jest to ustawienie domyślne AppWizard). W tym scenariuszu nie tylko kod jest dynamicznie połączony — tak samo jak zasoby. W związku z tym można lokalizować zasoby w aplikacji, ale zasoby implementacji MFC będą nadal ładowane z biblioteki MFC7x.DLL (lub nowszej) lub z biblioteki MFC7xLOC.DLL, jeśli istnieje. Można podejść do tego z dwóch różnych kątów.

Bardziej złożone podejście polega na wysłaniu jednej z zlokalizowanych bibliotek MFC7xLOC.DLL (takich jak MFC7xDEU, dla języka niemieckiego, MFC7xESP.DLL dla języka hiszpańskiego itp.) lub nowszej wersji i zainstalowania odpowiedniej biblioteki MFC7xLOC.DLL w katalogu systemowym podczas instalowania aplikacji przez użytkownika. Może to być bardzo złożone zarówno dla dewelopera, jak i użytkownika końcowego, a w związku z tym nie jest zalecane. Aby uzyskać więcej informacji na temat tej techniki i jej zastrzeżeń, zobacz Technical Note 56 (Uwaga techniczna 56 ).

Najprostszym i najbezpieczniejszym podejściem jest dołączenie zlokalizowanych zasobów MFC do aplikacji lub biblioteki DLL (lub jej biblioteki DLL satelitarnej, jeśli używasz). Pozwala to uniknąć problemów z prawidłową instalacją biblioteki MFC7xLOC.DLL. W tym celu należy postępować zgodnie z tymi samymi instrukcjami dotyczącymi statycznego przypadku podanego powyżej (prawidłowe ustawienie wiersza polecenia RC w celu wskazania zlokalizowanych zasobów), z tą różnicą, że należy również usunąć /D_AFXDLL definicję dodaną przez aplikację AppWizard. Po /D_AFXDLL zdefiniowaniu elementu AFXRES. H (i inne pliki MFC RC) nie definiują żadnych zasobów (ponieważ zostaną one ściągnięte z bibliotek DLL MFC).

Zobacz też

Uwagi techniczne według numerów
Uwagi techniczne według kategorii