Steuerelemente ansprechen?

AndRo67

Wo liegt eigentlich der Vorteil von GetDlgItem... gegenüber den Membervariablen?
Ich hab hier im Forum schon einige Beiträge gesehen, in denen GetDlgItem verwendet wird. Nur ist mir nicht ganz klar, was hieran besser ist als die Verknüpfung mit den Membervariablen, die von VC++ mit den Assistenten und Makros doch eigentlich ganz anständig unterstützt wird.

hehejo

Ich verknüfpe die Controls nicht über Membervariablen im Sinne von Edit->CString
sondern eher im Sinne von Edit->CEdit.
Das finde ich besser als das Gefuchtel mit UpdateData().
Bei UpdateData kommen nämlich alle Daten aus dem Dialog in deine Variablen und umgekehrt.
Was ist, wenn du aber nur einen Wert setzen möchtest?

Da mach ich z.B. lieber m_ctrleEdit123.SetWindowText("Hallo Editfeld.");.

GetDlgItem bennutze ich bei Controls die ich sonst im Programmgebrauch nicht immer benutzen möchte.
Das sind z.B. Statics die ich aber auch ausgrauen möchte.
Da langt mir dann ein GetDlgItem(IDC_STATIC_1)->EnableWindow(false);.

Taelan

für gewöhnlich arbeite ich bei Steuerelementen auch eher mit den Controls
allerdings hat sich CEdit->SetWindowText bei mehreren Zuweisungen als Fehlerhaft erwiesen, mag sein das ich hier wieder nur etwas falsch gemacht habe aber dies hat sich als funktionstüchtig erwiesen:

// Die Membervariablen des EditFeldes
CEdit m_cEdit;
CString m_Edit;
//-------------------------------------------------
m_cEdit.SetSel(0,m_Edit.GetLength()-1);
m_cEdit.ReplaceSel("TEst");

das wirkt auch auf mich recht umständlich aber wie gesagt bei SetWindowText haben sich teilweise Fehler in der Darstellung ergeben.

d.h. Für gewöhnlich reicht es wenn du dir die bereitgestellten Methoden der Controls anschaust, damit lässt sich eigentlich das meiste machen.

hehejo

Was für Fehler gab es denn bei dir?
Ich hatte damit noch nie Probleme!

CrazyOwl

AndRo67 schrieb:

Wo liegt eigentlich der Vorteil von GetDlgItem... gegenüber den Membervariablen?

Man muss die Membervariable nicht anlegen.

Unix-Tom

Um noch genauer zu sein. Es gibt Dialoge mit sehr vielen Steuerelementen.
Das ist dann eine Klickorgie wenn man für alles eine Variable anlegt.
Fehler in SetWindowText habe ich noch nie bemerkt. Denke da machst du was falsch.

AndRo67

Also, soweit ich dies verstanden habe, ist der Hauptvorteil der, dass man sich das "Rumgeklicke" im Assistenten spart.
Dafür hat man beim Zugriff mehr Schreibarbeit:

long lZahl = m_lZahl
gegen:
long lZahl = atol(GetDlgItem(IDC_ZAHL).GetWindowText())
oder:
long lZahl = atol(m_cZahlFeld.GetWindowText())

Und wo soll da der große Vorteil sein? Die Anlegerei im Assistenten mach ich nur einmal, den Zugriff brauche ich dauernd.

Für mich der einzige Vorteil ist wohl der, wenn ich nur eine Variable ändern will.
Andererseits kann ich mir dadurch wieder Probleme erkaufen, da nach dem Ändern einer einzelnen Variable eventuell eine Inkonsistenz zwischen den Daten in den Dialogfeldern und den Variablen besteht. Mit UpdateData habe ich dieses Problem nicht.

Unix-Tom

Es gibt eben auch Leute die mit Threads arbeiten.
Hast du schon UpdateData in einem Thread, der nicht der Hauptthread ist, aufgerufen?

@ hehejo,
nur mal am Rande, man braucht kein UpdateData(...) verwenden wenn man nur eine Dlg-Variable beschreiben/ auslesen will:

[C++]
	CDataExchange dfa(this,FALSE);
	DDX_Text(&dfa, ID_DES_DLG_ELEMENTS, m_membervar);

	CDataExchange dtr(this,TRUE);
	DDX_Text(&dtr, ID_DES_DLG_ELEMENTS, m_membervar);

wozu die Variablen über das Studio anlegen und warum nicht direkt im Quelltext kopieren, da spart man sich viele Klicks?

tester2

AndRo67

Okay, da gebe ich mich geschlagen
Mit Threads musste ich mich bislang noch nie auseinandersetzen.

Taelan

Hm, ich habs grad nochmal ausprobiert und das Problem das ich hatte hat sich in wohlgefallen aufgelöst
ka warum es damals nicht geklappt hat.

jedenfalls regt mich VC++ immer mehr auf da es ständig sachen macht die es nicht soll ^^
wie z.b. einfach mal mein Projekt beim compilieren zerschiessen