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
Opinia
https://aka.ms/ContentUserFeedback.
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź:Prześlij i wyświetl opinię dla