Menu in einer Mehrsprachigen-Anwendung

vielen Dank hab die Funktion überschrieben und jetzt läuft es Perfekt!

BOOL CKwlDoc::SaveModified()
{

	if ( !IsModified() )
		return TRUE;        // ok to continue

	CString prompt;
	prompt.Format(theApp.GetString(IDS_STRING_00424), m_strTitle);

	switch (MessageBox(NULL, prompt, theApp.GetString(IDS_STRING_00425), MB_YESNOCANCEL|MB_ICONQUESTION) )
	{
	case IDCANCEL:
		return FALSE;       // don't continue

	case IDYES:
		// If so, either Save or Update, as appropriate
		if (!DoFileSave())
			return FALSE;       // don't continue
		break;

	case IDNO:
		// If not saving changes, revert the document
		break;

	default:
		ASSERT(FALSE);
		break;
	}

	return TRUE;    // keep going
}

Achso wenn ich schon dabei bin kann ich euch auch gleich fragen wie man
Icons erstellt die Windows 7 tauglich sind (glaub 256x256 ) unter VC 6.

Habe leider nichts im Internet gefunden...

Softwaremaker

Hast du auch die Druckvorschau übersetzt? Denn die kommt von afxprint.rc, da gibts aber auch eine Lösung...

zu den Icons:
http://msdn.microsoft.com/en-us/library/ms997636.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa511280.aspx
der VS-Iconeditor kann keine 256-Farben, also anderes Tool verwenden.

Softwaremaker schrieb:

Hast du auch die Druckvorschau übersetzt? Denn die kommt von afxprint.rc, da gibts aber auch eine Lösung...

Ne die Druckvorschau habe ich ganz vergessen...aber habe bereits das hier gefunden für eine individuelle Vorschau:

void CPrintPreviewView::OnFileImprovedprintpreview() 
{
	// need to use CMyPreviewView class
	CPrintPreviewState* pState = new CPrintPreviewState;

	if (!DoPrintPreview(IDD_PREVIEW, this, RUNTIME_CLASS(CMyPreviewView), pState))
	{
		TRACE0("Error: OnFileImprovedprintpreview failed.\n");
		AfxMessageBox(AFX_IDP_COMMAND_FAILURE);
		delete pState;      // preview failed to initialize, delete State now
	}
}

Falls deine Lösung schöner ist bitte posten

Softwaremaker

Eine eigene PrintPreview-Klasse erstellen:

#include <afxpriv.h>

class CPreviewViewTrans : public CPreviewView  
{
public:
	DECLARE_DYNCREATE(CPreviewViewTrans)
	CPreviewViewTrans();
	void OnActivateView( BOOL bActivate, CView* pActivateView, CView* pDeactiveView );
protected:
	//{{AFX_MSG(CPreviewViewTrans)
	afx_msg void OnUpdateNumPageChange(CCmdUI* pCmdUI);
	//}}AFX_MSG
	DECLARE_MESSAGE_MAP()
};

#include "stdafx.h"
#include "CPreviewViewTrans.h"

IMPLEMENT_DYNCREATE(CPreviewViewTrans, CPreviewView)

BEGIN_MESSAGE_MAP(CPreviewViewTrans, CPreviewView)
	//{{AFX_MSG_MAP(CPreviewViewTrans)
	ON_UPDATE_COMMAND_UI(AFX_ID_PREVIEW_NUMPAGE, OnUpdateNumPageChange)
	//}}AFX_MSG_MAP
END_MESSAGE_MAP()

CPreviewViewTrans::CPreviewViewTrans()
{
}

void CPreviewViewTrans::OnActivateView(BOOL bActivate, CView*, CView*)
{
	if (bActivate)
	{
		if (m_pToolBar)
		{
			CWnd	*wnd;

			wnd = m_pToolBar->GetDlgItem(AFX_ID_PREVIEW_PRINT);
			if ( wnd ) wnd->SetWindowText( AFX_IDS_PREVIEW_PRINT );

			wnd = m_pToolBar->GetDlgItem(AFX_ID_PREVIEW_NEXT);
			if ( wnd ) wnd->SetWindowText( AFX_IDS_PREVIEW_NEXT );

			wnd = m_pToolBar->GetDlgItem(AFX_ID_PREVIEW_PREV);
			if ( wnd ) wnd->SetWindowText( AFX_IDS_PREVIEW_PREV );

			//AFX_ID_PREVIEW_NUMPAGE hat keinen Text

			wnd = m_pToolBar->GetDlgItem(AFX_ID_PREVIEW_ZOOMIN);
			if ( wnd ) wnd->SetWindowText( AFX_IDS_PREVIEW_ZOOMIN );

			wnd = m_pToolBar->GetDlgItem(AFX_ID_PREVIEW_ZOOMOUT);
			if ( wnd ) wnd->SetWindowText( AFX_IDS_PREVIEW_ZOOMOUT );

			wnd = m_pToolBar->GetDlgItem(AFX_ID_PREVIEW_CLOSE);
			if ( wnd ) wnd->SetWindowText( AFX_IDS_PREVIEW_CLOSE );
		}
	}
}

void CPreviewViewTrans::OnUpdateNumPageChange(CCmdUI* pCmdUI)
{
	CPreviewView::OnUpdateNumPageChange(pCmdUI);

	UINT nPages = (m_nZoomState == ZOOM_OUT ? m_nPages : m_nZoomOutPages);

	if (nPages == 1)
		pCmdUI->SetText( AFX_IDS_TWOPAGE );
	else
		pCmdUI->SetText( AFX_IDS_ONEPAGE );
}

//es gibt auch noch
//AFX_IDS_PREVIEWPAGEDESC  "Page %u\nPages %u-%u\n"
//das habe ich aber nicht in meinem Code

Und in View den Code den du schon hast (aber mit CPreviewViewTrans anstatt CMyPreviewView)

Super, vielen Dank

Leider funktioniert es nicht bei mir. Meine Druckervorschau ist von CEditView abgeleitet...gibts dort eine möglichkeiten, die Toolbar buttons umzubennen?

Softwaremaker

void CTestView::OnFilePrintPreview()
{
CEditView::OnFilePrintPreview(); <<--breakpoint setzen
}

Programm im Debugmode starten, Druck-Vorschau aufrufen > hält bei Breakpoint
F11 (eins weiter) >> du siehst CView::OnFilePrintPreview() und so wie es dort ist musst du es auch machen

CPrintPreviewState* pState = new CPrintPreviewState;

    if (!DoPrintPreview(AFX_IDD_PREVIEW_TOOLBAR, this, RUNTIME_CLASS(CPreviewViewTranslate), pState))
    {
        TRACE0("Error: OnFileImprovedprintpreview failed.\n");
        AfxMessageBox(AFX_IDP_COMMAND_FAILURE);
        delete pState;      // preview failed to initialize, delete State now
    }

Mmacher

Sven12 schrieb:

Achso wenn ich schon dabei bin kann ich euch auch gleich fragen wie man
Icons erstellt die Windows 7 tauglich sind (glaub 256x256 ) unter VC 6.

Der Resourcen-Editor von VS6 kennt Icon im Format 256x256 Pixel nicht. Das liegt daran, daß dieses Icon im *.PNG Format vorliegen muß (ab Windows Vista und neuer).
Die bisherigen (kleineren) Icons sind bekanntlich im *.BMP bzw. *.ICO Format (und diese werden bis heute natürlich weiterhin unterstützt)

Dazu brauchst Du also einen moderneren Icon-Designer.
Es gibt eine große Auswahl an kostenfreien Tools im Internet!

Nachdem Du ein entsprechendes Icon erzeugt hast, mußt Du es in die Resource-Sektion Deiner Applikation einbinden.
Da der Compiler bzw. Linker des VS6 auch damit nicht klarkommt, muß man es nach Abschluß des Buildens nachträglich mit einem externen Tool machen.

Ich habs mit Hilfe von ReplaceVistaIcon.exe gelöst, siehe CodeProject "Windows Vista Icons": http://www.codeproject.com/Articles/14010/Windows-Vista-Icons

HTH,
Martin

Danke Softwaremaker, Texte werden nun in der Vorschau auch übersetzt...flickert nur etwas aber nicht schlimm.

Und auch danke für den Tip

Mmacher schrieb:

Sven12 schrieb:

Achso wenn ich schon dabei bin kann ich euch auch gleich fragen wie man
Icons erstellt die Windows 7 tauglich sind (glaub 256x256 ) unter VC 6.

Der Resourcen-Editor von VS6 kennt Icon im Format 256x256 Pixel nicht. Das liegt daran, daß dieses Icon im *.PNG Format vorliegen muß (ab Windows Vista und neuer).
Die bisherigen (kleineren) Icons sind bekanntlich im *.BMP bzw. *.ICO Format (und diese werden bis heute natürlich weiterhin unterstützt)

Dazu brauchst Du also einen moderneren Icon-Designer.
Es gibt eine große Auswahl an kostenfreien Tools im Internet!

Nachdem Du ein entsprechendes Icon erzeugt hast, mußt Du es in die Resource-Sektion Deiner Applikation einbinden.
Da der Compiler bzw. Linker des VS6 auch damit nicht klarkommt, muß man es nach Abschluß des Buildens nachträglich mit einem externen Tool machen.

Ich habs mit Hilfe von ReplaceVistaIcon.exe gelöst, siehe CodeProject "Windows Vista Icons": http://www.codeproject.com/Articles/14010/Windows-Vista-Icons

HTH,
Martin

So hab jetzt noch ne Frage. Die Umstellung auf UNICODE verursacht probleme bzw. startet nicht mehr.

Muss die Hauptanwenung und DLL UNICODE sein oder reicht es wenn die DLL alleine UNICODE fähig ist?

Martin Richter

Sven12 schrieb:

So hab jetzt noch ne Frage. Die Umstellung auf UNICODE verursacht probleme bzw. startet nicht mehr.

Muss die Hauptanwenung und DLL UNICODE sein oder reicht es wenn die DLL alleine UNICODE fähig ist?

Was für eine DLL meinst Du?

Die DLL muss in Ihren Schnittstellen zur EXE passen. Mehr nicht.
Ob die nun intern Unicode oder MBCS nimmt ist wurscht.

Wenn Du in den Funktionen der DLL auch TCHAR LPT... etc. verwendes hast muss die natürlich zur EXE passen. Aber dann stürzt nichts ab, dann wird die DLL nicht geladen, sofern Du kein C-Interface verwendest.

Martin Richter schrieb:

Sven12 schrieb:

So hab jetzt noch ne Frage. Die Umstellung auf UNICODE verursacht probleme bzw. startet nicht mehr.

Muss die Hauptanwenung und DLL UNICODE sein oder reicht es wenn die DLL alleine UNICODE fähig ist?

Was für eine DLL meinst Du?

Die DLL muss in Ihren Schnittstellen zur EXE passen. Mehr nicht.
Ob die nun intern Unicode oder MBCS nimmt ist wurscht.

Wenn Du in den Funktionen der DLL auch TCHAR LPT... etc. verwendes hast muss die natürlich zur EXE passen. Aber dann stürzt nichts ab, dann wird die DLL nicht geladen, sofern Du kein C-Interface verwendest.

Meine DLL(s) besitzen nur Stringtables und Menüs welche von der Hauptanwendung geladen werden.

Wie auch immer habe nach der Umstellung auf UNICODE es nicht hinbekommen das Programm lauffähig zu machen, ist natürlich sehr Umfangreich + ich habe mich noch nie mit UNICODE befasst, deswegen möchte ich vorher Nachfragen bevor ich mich mit der Ursache beschäftige.

Mmacher

Sven12 schrieb:

Martin Richter schrieb:

Sven12 schrieb:

So hab jetzt noch ne Frage. Die Umstellung auf UNICODE verursacht probleme bzw. startet nicht mehr.

Muss die Hauptanwenung und DLL UNICODE sein oder reicht es wenn die DLL alleine UNICODE fähig ist?

Was für eine DLL meinst Du?

Die DLL muss in Ihren Schnittstellen zur EXE passen. Mehr nicht.
Ob die nun intern Unicode oder MBCS nimmt ist wurscht.

Wenn Du in den Funktionen der DLL auch TCHAR LPT... etc. verwendes hast muss die natürlich zur EXE passen. Aber dann stürzt nichts ab, dann wird die DLL nicht geladen, sofern Du kein C-Interface verwendest.

Meine DLL(s) besitzen nur Stringtables und Menüs welche von der Hauptanwendung geladen werden.

Wie auch immer habe nach der Umstellung auf UNICODE es nicht hinbekommen das Programm lauffähig zu machen, ist natürlich sehr Umfangreich + ich habe mich noch nie mit UNICODE befasst, deswegen möchte ich vorher Nachfragen bevor ich mich mit der Ursache beschäftige.

Da hilft es nur noch mit dem Debugger Step-by-Step zu debuggen.

Da Du von einem Absturz sprichst, obwohl in den DLLs nur Stringtables und Menüs sind:
Ich vermute, Du hast irgendwo in der EXE einen Speicher für Deine Strings angefordert bzw. char-Variablen bereitgestellt, aber mit der Anzahl von Zeichen, was bei ANSI 8-bit Zeichensatz auch funktioniert.
Sobald Du aber versuchst in diesen Speicher UNICODE 16-bit Texte zu kopieren, dann kann es krachen, weil UNICODE-Strings doppelt so viel Speicher benötigen als ANSI !!!

Nur mal so als Hilfestellung
Martin

Martin Richter

Debugger und Callstack sollte Dir doch hinreichend Informationen liefern!

OK Programmabsturz habe ich nun im Griff, nur werden die Zeichen immer noch als Symbole bzw. dicke I's angezeigt habe schon soviel versucht aber bisher kein Erfolg.

DLL:
C++ Prä...
WIN32,NDEBUG,_WINDOWS,_WINDLL,_AFXDLL,_UNICODE,_USRDLL
Res Prä...
NDEBUG,_AFXDLL,_UNICODE
Einstiegspunkt
_DllMainCRTStartup@12

und das gleiche bis auf den Einstiegspunkt auch in der Hauptanwendung.

Die *.rc Datei kann ich nur mit Notepad bearbeiten da ich sie als UNICODE gespeichert habe.

Mein Stringtable sieht so aus (gekürzt) für Tests:
IDS_STRING_00074 L"\x015B\u0107\uC59B\uC487"
IDS_STRING_00075 L"Miejscowość"

OK habe es gerade in auf Windows 7 probiert und dort wird es richtig angezeigt

Unter Windows XP werden immer noch nur Balken dargestellt? Hat einer ein für mich Tip?

Softwaremaker

Du musst direkt in der .rc die Fonts der Dialoge auf "MS Shell Dlg" ändern. Diesen Font gibt es nicht (deshalb auch nicht im VS-Dialog-Editor), aber Windows nimmt dann den optimalen Font (in DE zb. "MS Sans Serif").

http://msdn.microsoft.com/en-us/goglobal/bb688134

Fonts in Dialog Resource Files

System fonts are different from one language version to another (even within the same version of the operating system). Those in charge of translating resource files often do not have enough information or technical background on how to change the font face name–whether this change involves replacing the entire name or only modifying it slightly, such as when adding charset information–for the different languages into which they are translating text. In the following example, MS Sans Serif, a bitmap font that only contains glyphs for Western European languages, is being used in the dialog resources. If the application is localized into Turkish or Japanese and run on Windows 2000 or earlier versions, for example, without changing the font face name, the UI text will be displayed in the default glyph as empty squares. (See Figure 3.) This type of display occurs because MS Sans Serif is not an OpenType font that can accommodate Turkish script, and it is not font linked in the system, plus in Windows 2000 or earlier versions there is no font fallback.

Because the desired behavior is to have the UI font of your application follow the desktop (Shell) UI font, and because the default Shell font is different from one localized language of the operating system to another (for example, Microsoft Sans Serif for English, Tahoma for Arabic, and so on), the best practice is to always use the higher–level font face name known as "MS Shell Dlg." MS Shell Dlg is actually not a font. Rather, it is a font face name that gets mapped to the right font depending on the font–substitution settings of the operating system. By setting your default resource font as MS Shell Dlg, you are assured of providing the appropriate font solution, not only on Windows 2000 and Windows XP, but also on all versions of Windows since Windows 95!

Softwaremaker schrieb:

Du musst direkt in der .rc die Fonts der Dialoge auf "MS Shell Dlg" ändern. Diesen Font gibt es nicht (deshalb auch nicht im VS-Dialog-Editor), aber Windows nimmt dann den optimalen Font (in DE zb. "MS Sans Serif").

http://msdn.microsoft.com/en-us/goglobal/bb688134

Fonts in Dialog Resource Files

System fonts are different from one language version to another (even within the same version of the operating system). Those in charge of translating resource files often do not have enough information or technical background on how to change the font face name–whether this change involves replacing the entire name or only modifying it slightly, such as when adding charset information–for the different languages into which they are translating text. In the following example, MS Sans Serif, a bitmap font that only contains glyphs for Western European languages, is being used in the dialog resources. If the application is localized into Turkish or Japanese and run on Windows 2000 or earlier versions, for example, without changing the font face name, the UI text will be displayed in the default glyph as empty squares. (See Figure 3.) This type of display occurs because MS Sans Serif is not an OpenType font that can accommodate Turkish script, and it is not font linked in the system, plus in Windows 2000 or earlier versions there is no font fallback.

Because the desired behavior is to have the UI font of your application follow the desktop (Shell) UI font, and because the default Shell font is different from one localized language of the operating system to another (for example, Microsoft Sans Serif for English, Tahoma for Arabic, and so on), the best practice is to always use the higher–level font face name known as "MS Shell Dlg." MS Shell Dlg is actually not a font. Rather, it is a font face name that gets mapped to the right font depending on the font–substitution settings of the operating system. By setting your default resource font as MS Shell Dlg, you are assured of providing the appropriate font solution, not only on Windows 2000 and Windows XP, but also on all versions of Windows since Windows 95!

Das hat geholfen, Danke Danke Danke!