Menu in einer Mehrsprachigen-Anwendung

[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)

[Sven12]

Super, vielen Dank

[Sven12]

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
}

2. Programm im Debugmode starten, Druck-Vorschau aufrufen > hält bei Breakpoint
3. 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

[Sven12]

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

[Sven12]

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.

[Sven12]

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!

[Sven12]

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ść"

[Sven12]

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!

[Sven12]

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!