Eigene Dialogklasse und die ResourcenID

Hallo,

ich habe eine Klasse CMyDialog von CDialog abgeleitet. Desweiteren möchte ich für diverse Applikationen wiederverwendbare Dialogklassen samt Fenster (abgeleitet von CMyDialog) implementieren.
Bsp:

CMyStdDialog1 -> CMyDialog -> CDialog
CMyStdDialog2 -> CMyDialog -> CDialog

Nun braucht ja jede Dialogklasse eine ResourcenID der zugehörigen Fensterresource.

CMyStdDialog1 mit IDD_MYSTDDIALOG1
CMYStdDialog2 mit IDD_MYSTDDIALOG2

Fragen:

1. Wie kann ich das Fenster dauerhaft sichern ohne dabei bei jeder neuen Applikation (die diese Fensterklasse verwendet) dieses 'mühsam' aus einer anderen Applikation reinzukopieren?

2. Wie vermeide ich ResourcenID Konflikte im Hauptprogramm (CMyAppDlg) falls ich in diesen Basisklassen CMyStdDialog1, ect. eine fixe ID vergeben muß?
Muß dann alles mühsam von Hand korrigiert werden?

Weißt jemand Rat oder ist so ein Vorhaben mit MFC generell zu umständlich?

Bei den Applikationen handelt es sich dabei ausschließlich um dialogfeldbasierten Anwendungen, also keine SDI/MDI.

Source2702

Wenn du den identischen Dialog in verschiedenen Anwendungen verwenden möchtest, dann bietet sich doch eine DLL mit den Resourcen und deiner Dialog-Basisklasse an. Du exportierst aus dieser Klasse ganz einfach ein paar Funktionen, die deinen Dialog dann anzeigen.

Durch die DLL hast du beide deiner Anforderungen erfüllt.
1. Nix kopieren, nur DLL einbinden
2. Da die DLL ihre eigenen Resourcen hat, auch keine Konflikte mit der Hauptanwendug.

Martin Richter

Ich benutze für Common-Dialoge eine eigene RC Datei, die ich in eine andere RC Datei include und die einen getrennten Nummernkreis der Dialoge und Commands hat.

Das geht natürlich nur bis zu begrenzten Anzahl Dialoge.

Ansonsten können DLLs ein guter Ansatz sein, wenn man den Dalog selbst komplett kapseln kann, wie es MFC-Code geschrieben hat.

Martin Richter schrieb:

Ich benutze für Common-Dialoge eine eigene RC Datei, die ich in eine andere RC Datei include und die einen getrennten Nummernkreis der Dialoge und Commands hat.

Das geht natürlich nur bis zu begrenzten Anzahl Dialoge.

Wie legst du den Nummernkreis fest?
Wenn jede Appl so anfängt

//{{NO_DEPENDENCIES}}
// Microsoft Visual C++ generated include file.
// Used by MyAppl.rc
//
#define IDM_ABOUTBOX                    0x0010
#define IDD_ABOUTBOX                    100
#define IDS_ABOUTBOX                    101
#define IDD_MYAPPL_DIALOG               102

dann müßte man ja für die mehrfachbenutzten bei 1000, 2000, ect. anfangen um genug Reserve zu haben, sehe ich das richtig?

Leider bringen auch ein eigene Resourcendateien nichts, wenn insgesamt eine doppelte IDnummer vorkommt schöpft der Compiler Verdacht.

Könnte man sich nicht die IDnummer sparen und das Dialogdesign mühsam von Hand programmieren (so wie es bei SDI/MDI gemacht wird)?
Muss grundsätzlich immer eine DialogID existieren?

Martin Richter

Für die Comnon Dialoge benutze ich dann sehr hohe IDs.

30000 für Dialoge
31000 für Controls
54000 für Strings

Ale Projekte können dann diese Common-Dialoge benutzen.
So wie eben auch die MFC ID-Ranges reserviert hat.

Martin Richter schrieb:

Für die Comnon Dialoge benutze ich dann sehr hohe IDs.

30000 für Dialoge

So wie eben auch die MFC ID-Ranges reserviert hat.

Gibts da keine Probleme? Laut TN020 ist

Prefix Resource type Valid range
IDD_ dialog templates 1 through 0x6FFF

und 30k sind ja drüber.

Martin Richter

Ich glaube diese Restriktion ist noch aus uralten MFC Zeiten.
Genauso wie die Restriktion das ID_ Werte in Menüs >0x8000 sein müssen. Auch Quatsch (soweit ich den MFC COde keine).
Das war mal in einem alten Command-Routing drin, aber gefunden habe ich in den aktuellen Versionen nichts mehr...

Ich keine keine Codeteile in der MFC, die dasnoch benutzen.

Aber diese Entscheidung bei uns ist schon ziemlich alt. Ich finde keine Doku mehr dazu, warum wir es gemacht haben. TN020 ist laut interner Doku berücksichtigt worden. Aber warum es geht bzw. warum es keine Einschränkungen gibt habe ich leider nicht mehr auf dem Plan. Man wird halt alt..

Hi,

ich habs nun einfach ohne DLL gelöst (so mit eigener *.rc Datei + sonstigem Zeugs).
Allerdings kommt jetzt ein neues Problem:

in CMyDialog.h wird

public:
	bool CreateDlg (void);
	bool CreateDlg (int n_PosX = 0, int n_PosY = 0, bool bShowDlg = true);

deklariert.

Im Hauptprogramm wird

CreateDlg()

benutzt und dies erzeugt C2668.

Wie kann hier eine Mehrdeutigkeit interpretiert werden, wenn anhand der Argumente klar ist, welche der beiden Funktionen der Compiler nehmen soll?

hat sich erledigt.

CreateDlg(0)

und alles ist gut.