Menü wechseln

[suamikim]

Hallo zusammen!

Ich arbeite gerade daran, mein MDI-Programm Mehrsprachig zu machen und stehe vor einem Problem:

Beim umschalten der Sprache kann ich aus der jeweiligen Sprach-DLL meine Menüs laden (liegen als Ressource vor). Leider weiß ich nicht, wie ich da am besten vorgehe:

Momentan rufe ich einfach beim Sprach-Wechsel meine Methode SetMenu() aus meinem MainFrm auf, welche folgendermaßen arbeitet:

CMenu menu;
HMENU hMenu;

// Prüfen, ob bereits eine View geöffnet ist (mein Programm zeigt links einen Baum, in
// welchem alle geöffneten Views sichtbar sind, also prüfe ich, ob der Baum bereits
// Einträge enhält oder leer ist)
if (theApp.m_pTreeCtrl->GetFirstVisibleItem())
	{ // Es ist/sind bereits Dokument(e) offen
    // Das zur Sprache gehörige Typ-Menü laden
	hMenu = theApp.AppGetLangMenu(IDR_xxxTYPE);
	if (hMenu == NULL)
		return;
	}
else
	{ // Es wurde noch kein Dokument geöffnet
    // Das zur Sprache gehörige Main-Menü laden (wenn kein Dokument geöffnet ist)
	hMenu = theApp.AppGetLangMenu(IDR_MAINFRAME);
	if (hMenu == NULL)
		return;
	}

menu.Attach(hMenu);

CWnd::SetMenu(&menu);

Nun hab ich aber folgendes Problem:

Menü beim start des Programms (Standard-Menü):
http://www.ras-kas.net/Pics/lang_menu_1.jpg

Benutzer ändert die Sprache:
http://www.ras-kas.net/Pics/lang_menu_2.jpg

Neues Sprach-Menü wurde richtig geladen:
http://www.ras-kas.net/Pics/lang_menu_3.jpg

Benutzer öffnet neues Dokument:
http://www.ras-kas.net/Pics/lang_menu_4.jpg

Nun wird natürlich wieder das Standard Typ-Menü geladen und nicht jenes der eingestellten Sprache. Wenn der Benutzer nun alle geöffneten Dokumente schließt erscheint auch wieder das Standard Main-Menü (1. Link) und nicht jenes der eingestellten Sprache (3. Link).

Wie kann ich dieses Verhalten ändern, bzw. wo kann ich auf den Wechsel zwischen Standard und Typ-Spezifischem Menü reagieren?

Ich hoffe ihr könnt mir folgen, worin mein Problem liegt und mir ein wenig auf die Sprünge helfen!

danke, mfg

mike

[CStoll]

Ich bin mir jetzt nicht sicher, ob das genau dein Problem löst, aber eventuell wäre der Artikel eine MFC-Anwendung Mehrsprachfähig erstellen zumindest ein Ansatzpunkt für dich.

[suamikim]

Dankeschön, ein Ansatzpunkt ist das schon, kann aber meine Fragen leider auch nicht beantworten.

Also weitere Antworten sind durchaus noch erwünscht!

mfg

[LowFly]

wenn du zB. in der CMainFrame willst das sich dort beim klick auf dokument neu das menu ändert must du dir ne fuction dafür anlegen was passieren soll. einmal must du jetzt dafür sorge tragen das sich ein neues Document Teil 1 / neuses document Teil 2 öffnet und zweitens das das standartmenu das in der C...App::InitInstance() unter

CMultiDocTemplate* pDocTemplate;
pDocTemplate = new CMultiDocTemplate(
	IDR_CHANGETYPE,//<--Das menu was bei jedem document mitgeladen wird
	RUNTIME_CLASS(CChangeViewsDoc),
	RUNTIME_CLASS(CChildFrame), 
	RUNTIME_CLASS(CChangeViewsView));
	AddDocTemplate(pDocTemplate);

bei jedem neuen document mitgeladen wird wieder zerstöhsten und an dieser stelle ein neues erstellen. Ferner brauchst du dann natürlich ein paar variablen mit denen du steuern kannst welches menu gerade geladen werden soll.

//Auserhalb der classe
static UINT MENULANGUAGE [2]={IDR_MENUGERMAN, IDR_MENUENGLISH};
static int m_iLanguage;

//Neues menu erstellen
CMenu *MenuCtrl = new CMenu;
MenuCtrl->LoadMenu(MENULANGUAGE[m_iLanguage]);//Mit der richtigen ID laden

SetMenu(NULL);//Altes menu zerstöhren

SetMenu(MenuCtrl);//Neues menu setzen
delete MenuCtrl;

die ganze funktion für neues Document öffen aus der Mainframe sieht dann ungefähr so aus. aus einer C...View entnimm den code aus dem Thread von Teil 1

CDocument *pDoc = new CDocument();

CFrameWnd *frameWnd = ((CChangeViewsApp*)AfxGetApp())->m_pDocFormView->CreateNewFrame(pDoc, NULL);

frameWnd->InitialUpdateFrame(pDoc, TRUE);

CMenu *MenuCtrl = new CMenu;
MenuCtrl->LoadMenu(MENULANGUAGE[m_iLanguage]);

SetMenu(NULL);

SetMenu(MenuCtrl);

delete MenuCtrl;
delete pDoc;

auf jeden fall MUST du jetzt in jeder C....View und CMainFrame dafür sorge tragen was passieren soll wenn ein neues Document geöffnet wird. um es nicht zuviel code in den Einzelnen klassen werden zu lassen würde sich für ein neues document öffnen fast schon ne eigene classe empfehlen, da auser die inizialisierung von *pDoc es immer wieder der selbe code ist.

[suamikim]

Hm, irgendwie steig ich da noch nicht so ganz durch...

Beim erzeugen eines neuen Dokuments ändert sich das Menü doch schon automatisch. Dafür hab ich also nichts ändern müssen -> das erstellen des zuständigen Codes wurde beim erstellen des Projekts automatisch generiert.

Warum soll ich also das erstellen des neues Frame-Windows selbst wie von dir gezeigt übernehmen?

Nach meiner Vorstellung müsste ich ja nur jene Codestelle finden, an der das Menü des neuen Frame-Windows erzeugt wird und hier meinen Code einfügen (also laden des der eingestellten Sprache entsprechenden Menüs)?

Respektive bräuchte ich natürlich auch jene Codestelle, an der das Main-Menü wieder hergestellt wird, wenn die letzte sichtbare View (Dokument) geschlossen wird.

Bitte korrigier mich, wenn ich total daneben liege oder dich einfach falsch verstanden habe.

mfg

[LowFly]

Bitte korrigier mich, wenn ich total daneben liege oder dich einfach falsch verstanden habe

japp das tust du. denke ich oder wir reden gänzlich aneinander vorbei

wenn ich dich richtig verstanden hab ändert sich das menu den spracheinstellungen entsprechend. das heist solange du keine weiter c...view öffnest stimmt das menu. aber wenn du eine neue C.view öffnest läd es das standartmenu und nicht das was es den spracheinstellungen nach laden sollte.

Beim erzeugen eines neuen Dokuments ändert sich das Menü doch schon automatisch. Dafür hab ich also nichts ändern müssen -> das erstellen des zuständigen Codes wurde beim erstellen des Projekts automatisch generiert.

sagtest du nicht

Benutzer öffnet neues Dokument:
http://www.ras-kas.net/Pics/lang_menu_4.jpg

Nun wird natürlich wieder das Standard Typ-Menü geladen und nicht jenes der eingestellten Sprache. Wenn der Benutzer nun alle geöffneten Dokumente schließt erscheint auch wieder das Standard Main-Menü (1. Link) und nicht jenes der eingestellten Sprache (3. Link).

weil genau das passiert bin ich der meinung das du wenn du ein bestimmtest menu laden will selbst sorge dafür tragen must. indem du das alte zerstörst und eine neues den spracheinstellungen entsprechen laden must und das tust du am besten dort wo es passiert (ID_FILE_NEW Methode).

das standartmenu wird in der C...App::InitInstance() unter pDocTemplate = new CMultiDocTemplate... fetsgelegt. da kommst du meines wissens nicht hin. kann mich aber auch täuschen.

den weg den ich dir jetzt vorschlage ist in jeder C...View und MainFram die ID_FILE_NEW Methode zu überschreiben. wie das geht dazu hab ich dir die links gegeben. da ich eben keine andere möglichkeit sehe an das menu zu kommen, da es bei jedem neuen document automatisch geladen wird, durch die deklaration in der C...App::InitInstance().

wenn du dir zB eine neue klasse anlegen würdest und in der C...App::InitInstance() die deklaration CMultiDocTemplate* pDocTemplate; in die C...App.h schreiben würdest CMultiDocTemplate* m_pDocTemplate; könntest du aus jeder beliebigen C...View & auch eben der MainFrame in der Function der Methode ID_FILE_NEW bequem mit ein paar zeilen code erreichen das zu jeder zeit das richtige menu geladen wird in die neue klasse must du natürlich dann auch wieder die MainFrm.h und c...App.h includen.

C...View::OnFileNew()
{
	CDocument *pDoc = (CDocument*)GetDocument();
	OpenNewDocument(pDoc, m_pDocTemplate, MENULANGUAGE[m_iLanguage]);
	delete pDoc;

}
CMainFrame::OnFileNew()
{
	CDocument *pDoc = new CDocument();
	OpenNewDocument(pDoc, m_pDocTemplate, MENULANGUAGE[m_iLanguage]);
	delete pDoc;

}

CBlub::OpenNewDocument(CDocument *pDoc, CMultiDocTemplate *pMultiDoc, UINT uiMenu)
{

	CFrameWnd *frameWnd = ((CChangeViewsApp*)AfxGetApp())->pMultiDoc->CreateNewFrame(pDoc, NULL);

	frameWnd->InitialUpdateFrame(pDoc, TRUE);

	CMenu *MenuCtrl = new CMenu;
	MenuCtrl->LoadMenu(uiMenu);

	SetMenu(NULL);

	SetMenu(MenuCtrl);

	delete MenuCtrl;

}

[suamikim]

Soda, hab das ganze jetzt mal umgesetzt allerdings funktioniert das noch nicht so, wie ich will.

Zuerst mal im detail, wie ich das ganze implementiert habe:

Meinem App die Membervariable

CMultiDocTemplate* m_pDocTemplate;

hinzugefügt.

InitInstance der App abgeändert (m_pDocTemplate statt neuem CMultiDocTemplate-Pointer):

m_pDocTemplate = new CMultiDocTemplate(IDR_xxxTYPE,
		RUNTIME_CLASS(xxxDoc),
		RUNTIME_CLASS(CChildFrame), // custom MDI child frame
		RUNTIME_CLASS(xxxView));
	if (!m_pDocTemplate)
		return FALSE;
	AddDocTemplate(m_pDocTemplate);

MainFrame (OnNewFile):

CMenu menu;
	HMENU hMenu = theApp.AppGetLangMenu(IDR_xxxTYPE);
	if (hMenu == NULL)
		return;

	menu.Attach(hMenu);

	CxxxDoc *pDoc = new CxxxDoc();
	CFrameWnd *frameWnd = theApp.m_pDocTemplate->CreateNewFrame(pDoc, NULL);
	frameWnd->InitialUpdateFrame(pDoc, TRUE);

	CWnd::SetMenu(NULL);
	CWnd::SetMenu(&menu);

	//delete pDoc;

Ist doch richtig, dass ich hier nicht CDocument, sondern CxxxDoc verwende (CDocument ist nur eine abstrakte Klasse und kann nicht instanziert werden!)?

Wenn ich pDoc lösche schlägt ein Assert fehl, sobald die View das Dokument mittels GetDocument holen möchte...

View (OnNewFile):

CMenu menu;
	HMENU hMenu = theApp.AppGetLangMenu(IDR_xxxTYPE);
	if (hMenu == NULL)
		return;

	menu.Attach(hMenu);

	CxxxDoc *pDoc = GetDocument();
	CFrameWnd *frameWnd = theApp.m_pDocTemplate->CreateNewFrame(pDoc, NULL);
	frameWnd->InitialUpdateFrame(pDoc, TRUE);

	CWnd::SetMenu(NULL);
	CWnd::SetMenu(&menu);

	delete pDoc;

Eigentlich keine große Änderung bezüglich des oben vorgeschlagenen Codes vorgenommen (außer wieder CxxxDoc statt CDocument).

Nun meine Probleme:

- Wenn ich ein neues Dokument öffne wird kein neuer Standard-Name mehr vergeben (xxx1.xx). Menüleiste sah zuvor nach öffnen einer neuen Dokuments immer folgendermaßen aus: xxx - [xxx1.xxx]
- Die neue View bekommt keinen eigenen Verkleinern-, Vergrößern- & Schließen-Button mehr (So sollte es aussehen, So sieht es aus).

Weiters muss ich das ganze ja dann noch so erweitern, dass das Menü nicht nur beim öffnen eines neuen sondern auch beim öffnen eines bereits bestehenden Dokuments geladen wird (was aber hoffentlich kein allzu großes Problem darstellen sollte).

Hoffentlich kann mir nun auch noch wer weiterhelfen!

danke, mfg

ps.: Die xxx stehen für den Namen des Programms!

[suamikim]

@LowFly und alle anderen!

Keiner mehr eine Ahnung?

Sorry fürs pushen, will nicht, dass der Thread vergessen wird, wenn ich mir doch sicher bin, dass es hier wen gibt, der mir weiterhelfen kann!

danke, mfg

[LowFly]

jo sorry hab dich tutal vergessen wollt eigendlich antworten aber der thread ist nach unten durchgerutscht.

warum nimmst du nicht

CDocument *pDoc = new CDocument();

sondern

CxxxDoc *pDoc = new CxxxDoc();

da motzt bei mir der compiler

Compiler schrieb:

Kein Zugriff auf protected Element, dessen Deklaration in der Klasse "C...Doc" erfolgte

das funst nur wenn ich die deklaration public mach und die is ja nicht umsonst protected.
CDocument funst bei mir an dieser stelle ohne probleme auch das delete pDoc;

ja und wie gesagt du bist jetzt dafür verantwortlich was bei der erstellung des Documentes passiert somit must du ihm auch einen Namen gebene wenn du es willst.
ich ahb da grad mal ein wenig rumgespielt wie unten folgt geb ich den documenten so wieder einen titel jedoch ist GetTypeInfoCount nicht das richtige da 2 documente der gleichen art immer noch 0 documente sind war ein versuch ich habs jetzt mal dringelassen damit i in format einen wert hat.

int i = pDoc->GetTypeInfoCount();

CString sText,sWindowText;
GetWindowText(sWindowText);

sText.Format("%s EditView%i",sWindowText,i);
SetWindowText(sText);
sText.Format("EditView%i",i);
pDoc->SetTitle(sText);

was das mit dem systembutten verkleinern vergrößern usw.. auf sich hat kann ich jetzt nur raten aber hast du zufällig die PreCreateWindow function bzw die CREATESTRUCT des Fensters geändert oder ist diese in deiner classe forhanden, nur so verschwinden die nämlich.

NEW EDIT;
was mir da grad noch so eingefallen ist, für die fenstertitel erstellung wäre eigendlich der richtige platz in dem CDocument::NewDocument da ja die MainFrame immer den Documententitel annimmt.

[suamikim]

LowFly schrieb:

jo sorry hab dich tutal vergessen wollt eigendlich antworten aber der thread ist nach unten durchgerutscht.

Na dann is ja gut, dass ich den Thread gepusht habe

LowFly schrieb:

warum nimmst du nicht

CDocument *pDoc = new CDocument();

sondern

CxxxDoc *pDoc = new CxxxDoc();

da motzt bei mir der compiler

Compiler schrieb:

Kein Zugriff auf protected Element, dessen Deklaration in der Klasse "C...Doc" erfolgte

das funst nur wenn ich die deklaration public mach und die is ja nicht umsonst protected.
CDocument funst bei mir an dieser stelle ohne probleme auch das delete pDoc;

Wie oben bereits geschrieben kann ich CDocument nicht instanzieren, weil es eine abstrakte Klasse ist (genaue Compiler-Meldung: "error C2259: 'CDocument' : cannot instantiate abstract class").
Dazu hab ich natürlich die deklaration von CxxxDoc public gemacht (schon klar, dass das nicht sein soll, aber nachdem es anders nicht funzt...).

Die Sache mit dem Namen sollte kein allzu großes Problem sein. Durchlaufe einfach alle offenen Dokumente und werd so schon herausfinden, welche fortlaufende Zahl die nächste ist

LowFly schrieb:

was das mit dem systembutten verkleinern vergrößern usw.. auf sich hat kann ich jetzt nur raten aber hast du zufällig die PreCreateWindow function bzw die CREATESTRUCT des Fensters geändert oder ist diese in deiner classe forhanden, nur so verschwinden die nämlich.

Die PreCreateWindow ist in folgenden Klassen vorhanden: CMainFrame, CxxxView & CChildFrm.
Geändert wurde sie nur in der CxxxView, wobei diese im Original lediglich eine Anweisung ausführt:

return CView::PreCreateWindow(cs);

Bei mir wurde nur das CView auf CScrollView geändert:

return CScrollView::PreCreateWindow(cs);

Kann das hierfür der Grund sein?
Auch die CREATESTRUCT wird sonst eigentlich nirgends verwendet oder verändert (wird eben nur in den PreCreateWindow-Funktionen als Parameter übergeben aber nicht angerührt)...

mfg

[LowFly]

hmm geh ich richtig in der annahme das du vc8 bzw 2005 version hast?
dann versuch mal eine neue Documentenclasse zu erstellen diese von CDocument abzuleiten so hat es zumindest linus gemacht der hatte das gleiche problem mit der abstracten klasse.

das mit systembutten verkleinern vergrößern usw.. denke ich kommt daher das
die CScrollView::PreCreateWindow(cs) evtl nicht den Flag für Systemenu hat.
evtl könntest du auch mal versuchen bevor du die CREATESTRUCT an CScrollView::PreCreateWindow(cs) sie von dem actuellen fenster zu holen. wenn das ncit hilft halt den flag setzen.

[suamikim]

LowFly schrieb:

hmm geh ich richtig in der annahme das du vc8 bzw 2005 version hast?
dann versuch mal eine neue Documentenclasse zu erstellen diese von CDocument abzuleiten so hat es zumindest linus gemacht der hatte das gleiche problem mit der abstracten klasse.

Jep, du gehst richtig in der Annahme. VS 2005

LowFly schrieb:

evtl könntest du auch mal versuchen bevor du die CREATESTRUCT an CScrollView::PreCreateWindow(cs) sie von dem actuellen fenster zu holen. wenn das ncit hilft halt den flag setzen.

Wie kann ich die vom aktuellen Fenster holen? Das Flag weiß ich zwar gerade auch nicht, aber das lässt sich ja in der MSDN finden

Hab gerade keine Zeit das ganze auszuprobieren, werde es aber später mal versuchen!

danke, mfg

[LowFly]

ja muste auch erst nachkucken in der MSDN
an den style kommst du evtl mit .

DWORD dwStyle = (DWORD)GetWindowLong(m_hWnd, GWL_STYLE);
dwStyle  &= ~WS_MAXIMIZEBOX;//Deaktiviert die Maximieren button
dwStyle  &= ~WS_MINIMIZEBOX;//Deaktiviert die Minimieren button
cs.style = dwStyle;
CScrollView::PreCreateWindow(cs);

bzw könntest du ihn auch direct von der Function holen

BOOL C...::PreCreateWindow(CREATESTRUCT& cs)
{
	cs.style |= WS_SYSMENU;//Systemenu hinzufügen
	cs.style &= ~WS_MAXIMIZEBOX;//Deaktiviert die Maximieren button
	cs.style &= ~WS_MINIMIZEBOX;//Deaktiviert die Minimieren button
	return CScrollView::PreCreateWindow(cs);
}

und die styles findest du unter WS_

[suamikim]

Soda mir reichts jetzt!

Irgendwie funktioniert hier überhaupt nichts mehr...

Gibt es nicht irgend einen einfacheren Weg das ganze zu lösen?

Dabei könnte ich mir vorstellen einfach auf die 2 unterschiedlichen Menüs zu verzichten und immer das selbe zu zeigen (also das gleiche Menü beim start des Programms, bzw. wenn kein Dokument mehr geöffnet ist und wenn Dokument(e) geöffnet sind).
Dabei sollten halt lediglich jene Funktionen, die ohne geöffnetes Dokument keinen Sinn machen deaktiviert sein (ist ja denke ich Standardmäßig so, wenn keine View geöffnet ist, welche die Messages empfängt).

Dann müsste ich ja lediglich beim ändern der Sprache das Menü austauschen und fertig??? Was müsste ich im Programm jetzt umstellen, damit nur noch 1 Menü verwendet wird (Stichwort CMultiDocTemplate im App)?

Danke für die große Ausdauer mit mir. Hoffentlich könnt ihr mir auch weiterhin helfen!

mfg

[LowFly]

Was müsste ich im Programm jetzt umstellen, damit nur noch 1 Menü verwendet wird (Stichwort CMultiDocTemplate im App)?

hmm versteh nicht ganz was du meinst

m_pDocTemplate = new CMultiDocTemplate(
        [b]IDR_MENUDASGELADENWIRD[/b],//<----das ist das Menu was immer geladen wird
        RUNTIME_CLASS(xxxDoc),
        RUNTIME_CLASS(CChildFrame), 
        RUNTIME_CLASS(xxxView));

[suamikim]

Ohne das jetzt ausprobiert zu haben steh ich dann aber wieder vor dem Problem, dass bei jedem öffnen eines neuen Dokuments wieder das Standard-Menü (also in dem Fall Englisch) geladen wird und nicht jenes, dass aktuelle eingestellt ist (also zB. Deutsch).

Naja, werd mal wieder ein wenig herumspielen und trotzdem nicht weiterkommen (sorry, aber schön langsam nervt mich das ganze einfach)

mfg

[LowFly]

also was mir da noch einfallen würde bzw. schon länger ist,
erstell dir doch in der App einfach ein zweites MultiDocTemplate

m_pDocTempEng = new CMultiDocTemplate(
        IDR_MENU_ENGLISH,
        RUNTIME_CLASS(xxxDoc),
        RUNTIME_CLASS(CChildFrame), 
        RUNTIME_CLASS(xxxView));

m_pDocTempGer = new CMultiDocTemplate(
        IDR_MENU_GERMAN,
        RUNTIME_CLASS(xxxDoc),
        RUNTIME_CLASS(CChildFrame), 
        RUNTIME_CLASS(xxxView));

je nachdem welche sprache eingestellt wurde übergibst du zu Beginn an

AddDocTemplate(....);

das jeweilige MultiDoc für die Sprache des Menus.

und evtl würde es gehn das du wärend der laufzeit mit

((CChangeViewsApp*)AfxGetApp())->AddDocTemplate(NULL);
((CChangeViewsApp*)AfxGetApp())->AddDocTemplate(m_pDocTemp...);

das MultiDoc änderst aber das hab ich jetzt nicht probiert wäre nur sone idee

[suamikim]

LowFly schrieb:

m_pDocTemplate = new CMultiDocTemplate(
        [b]IDR_MENUDASGELADENWIRD[/b],//<----das ist das Menu was immer geladen wird
        RUNTIME_CLASS(xxxDoc),
        RUNTIME_CLASS(CChildFrame), 
        RUNTIME_CLASS(xxxView));

Hab das jetzt mal versucht, aber irgendwie ändert das nichts:

Der Aufruf sieht jetzt folgendermaßen aus:

m_pDocTemplate = new CMultiDocTemplate(IDR_xxxTYPE,
		RUNTIME_CLASS(CxxxDoc),
		RUNTIME_CLASS(CChildFrame), // custom MDI child frame
		RUNTIME_CLASS(CxxxView));

	if (!m_pDocTemplate)
		return FALSE;

	AddDocTemplate(m_pDocTemplate);

Angezeigt wird beim Programmstart trotzdem nicht das Menü IDR_xxxType, sonder IDR_MAINFRAME, also wird das Menü wohl wo anders geladen. Die Frage ist nur, wo? (Das Problem hab ich jetzt umgangen, indem ich in der InitInstance ganz am Schluss einfach mein AppChangeLanguage aufrufe, welches unter anderem auch die unten geschilderte Methode SetMenu vom MeinFrame ausführt. So wird anhand eines Registry-Eintrages zumindest beim Start das zuvor verwendete Sprach-Menü angezeigt ;))

LowFly schrieb:

also was mir da noch einfallen würde bzw. schon länger ist,
erstell dir doch in der App einfach ein zweites MultiDocTemplate

m_pDocTempEng = new CMultiDocTemplate(
        IDR_MENU_ENGLISH,
        RUNTIME_CLASS(xxxDoc),
        RUNTIME_CLASS(CChildFrame), 
        RUNTIME_CLASS(xxxView));

m_pDocTempGer = new CMultiDocTemplate(
        IDR_MENU_GERMAN,
        RUNTIME_CLASS(xxxDoc),
        RUNTIME_CLASS(CChildFrame), 
        RUNTIME_CLASS(xxxView));

Das kann ich nicht machen, da die Sprach-Ressourcen nicht fix im Programm eingebetet sind, sondern als Sprach-Dll's zur Verfügung stehen, welche dynamisch geladen werden, dh. das Programm weiß im Prinzip gar nicht, welche Sprachen vorhanden sind (das ganze soll einfach und vor allem unbegrenzt erweiterbar sein).

Die Umschaltung der Sprache erfolgt über folgende Methode, die im FrmMain definiert ist:

void CMainFrame::SetMenu()
	{
	CMenu menu;
	HMENU hMenu;

	hMenu = theApp.AppGetLangMenu(IDR_xxxTYPE);
	if (hMenu == NULL)
		return;

	menu.Attach(hMenu);

	CWnd::SetMenu(NULL);
	CWnd::SetMenu(&menu);
	::DrawMenuBar(m_hWnd);
	}

Beim starten des Programms wird über eben diesen Befehl das Menü der zuletzt verwendeten Sprache geladen. Nun stehe ich wieder vor dem Problem, dass beim öffnen eines neuen Dokuments wieder das Standard-Menü und nicht das Sprach-Spezifische geladen wird.

Und noch ein (bereits bekanntes) Problem: Wenn ein Dokument geöffnet wurde und ich dann erst die Sprache umschalte (mit oben geposteter Methode) verschwinden die System-Button (maximieren, minimieren, schließen) des Dokuments...

Ich weiß, dass sich das alles schon ziemlich im Kreis dreht und das bestimmt für euch/dich schon ziemlich nervig und anstrengend sein muss, aber ich hoffe trotzdem, dass ich gemeinsam mit euch eine Lösung finden kann!

danke, mfg

[LowFly]

hmm also als allerletzte möglichkeit würde mir jetzt noch einfallen menupunkte gezielt zu zerstöhren & wieder neu zu beschriften. kuck dir mal die klasse CMenu genauer an. du kannst jeden einzelnen menupunkt in einem bereits bestehenden Menu zerstöhren und an seiner stellen einen anderen Menupunkt einfügen.

nur ist halt ne crasse arbeit das zu bewerkstelligen.

[suamikim]

Die Möglichkeit ist mir auch schon in den Sinn gekommen, allerdings hab ich sie gleich wieder verworfen (wegen dem doch relativ großen Aufwand). Vor allem ist das Programm noch nicht ganz fertig, dass heißt bei jeder Änderung des Menüs entsteht hier wieder ein "unnötig" großer Aufwand...

Naja, sollte ich anders wirklich nicht weiterkommen wird es wohl keine andere Möglichkeit als diese geben.

danke, mfg