Visual c++ 6.0 und Dialoge...

[Saturo]

Hi, ich habe mit visual c++ eine Dialogbox erstellt. Leider komm ich nicht drauf, wie ich auf das Eingabefeld zugreifen kann...

[Crush]

Ich habe das hier einmal für einen Fortschrittbalken beschrieben, aber der Ablauf ist für fast jedes Dialogelement gleich. Du kannst dasselbe mit Deinem Dialog machen. Benutze am Besten wo es geht die Member-Variablen, da der Zugriff über die Handles auch unnötige Schreibarbeit ist.

http://217.115.144.9/cgi-bin/ubbcgi/ultimatebb.cgi?ubb=get_topic&f=21&t=000389&counterhit=yes

[Saturo]

ARGH!!!!!!!!!!!! DAS GIBBET NICHT!!!!!

Danke fuer die Tipps...aber es funzt einfach nicht! Und das geilste: es funktioniert wie immer alles ohne Fehlermeldung, nur zeigt er kein Ergebnis an...also nochmal von vorne:

Ich habe eine Dialogfeldbasierende MFC-Anwendung vom Assistenten erstellen lassen. Jetzt habe ich 2 Felder eingefügt..1. ein Static und 2. Ein Eingabefeld.

Man soll in das Eingabefeld seinen Namen schreiben und das soll beim Ok-Click dann im Staticfeld(textfeld) erscheinen.

So, ich habe also die beiden Membervariablen(DAVON IST DIE vom Textfeld NICHT AUF WERT SONDERN AUF STATIC deklariert) erzeugt und in die Onclick-function des OK-Buttons folgendes geschrieben:

m_ausgabe.SetDlgItemText(IDC_ST,m_eingabe);

M_ausgabe ist die Memberv. des textfeldes, und m_eingabe die des Eingabefeldes. IDC_ST ist die Kennung des Textfeldes. Supergut...er kompiliert, es klappt, aber das Staticfeld ändert sich einfach nicht!!! argh! Ich habe es mit UpdateData(); versucht...ebenso mit SetWindowText(oder so aehnlich)...aber überall dasselbe ergebnis...ich sitze jetzt schon 3 h daran...habe sämtliche Bücher gewälzt..aber meint ihr die netten Herren von Microsoft schreiben in ihrer Anleitung wie das geht??????? noe...vielleicht wird es ja auch erst ab xp version 20024e32 unterstuetzt...wenn nicht, dann wäre ich euch über einen Zaunpfahlwink auf meinen Denkfehler sehr verbunden...gn8 allerseits!

[Crush]

Das ist wirklich schwierig, es gab nur eine Kombination, die ein Auslesen und Ändern der Textfelder korrekt erledigt hat. Beide waren als Wert und CString (CEdit Objekte) eingebunden. Funktionen, die normal kompilierten und eigentlich die Werte abfragen sollten haben nicht richtig funktioniert. Die Inhalte des Feldes wurden nicht eingetragen und auch nicht richtig ausgelesen, obwohl der Compiler sich nicht beklagt hat. Woran das nun genau liegt weiß ich auch nicht. Man benötigt auch keine UpdateData() oder ähnliches. Dies ist übrigens auch gleich die kürzeste Methode zum Transferieren der Inhalte.

Ich zeige Dir mal mein OnButton():

void CTest8Dlg::OnButton1()

{

CString buffer;

m_Eingabe.GetWindowText(buffer);

m_Ausgabe.SetWindowText((LPCSTR)buffer);

}

Ist die einzigste Möglichkeit, die auch wirklich funktioniert. Jetzt frage ich mich, warum das so ist??? Keine Ahnung? Die anderen Abfragemethoden hätten eigentlich auch funktionieren sollen. Ich verstehe Dich, denn das ist eigentlich nicht gerade CPP-Standard eine solch eingeschränkte Zugriffsmöglichkeit zu bieten. Da das allerdings der Umgang mit ein paar der fundamentalsten Controls für Ein-/Ausgaben in Windows ist, gibt es wohl nur eine Möglichkeit: AUSWENDIG lernen und NICHT VERGESSEN!

Das mit SetDlgItemText() funktioniert schon auch, jedenfalls beklagt er sich nicht nur der Text der Eingabe wird nicht ausgelesen oder eingefügt! Vielleicht hat ein Edit-Feld einfach gar kein Item, bietet aber halt von irgendwoher die Schnittstelle an, die aber die Item-Datas ins Leere schickt! Das Feld enthält ja nur einen Wert! Ein Setzen des Items und wieder auslesen über die Item-Methode klappt ja auch nicht, was der Beweis ist.

Wieder mal was gelernt ... man lernt eben nie aus! Mit Sicherheit ist das eine der ersten Stolperfallen, die einem so beim Windows-Programmieren gestellt werden. Ich kann mich erinnern, daß ich vor ca. anderthalb Jahren an dem selben Problem ewig rumgesessen bin, das habe ich bis heute nie vergessen. Aber solche fiesen Probleme sind zum Glück nicht mehr allzu oft aufgetaucht. Also laß Dich davon bloß nicht unterkriegen und deprimieren - später läuft alles immer besser!

(Überleg Dir doch mal, Du hättest für die 3 Stunden Arbeit bei einem Stundenlohn von 80 DM schon eine richtige Party schmeißen können! Bei Auftragsarbeiten als Selbständiger sind nebenbei 150-250 DM Stundenlohn keine Seltenheit!!!) Aber für solche seelischen Grausamkeiten die ein Programmierer ertragen muß wird er leider nicht gerne bezahlt, sondern nur für den Output (oft in Zeilen) - schade)

<FONT COLOR="#a62a2a" SIZE="1">[ 02. November 2001 10:14: Beitrag 6 mal editiert, zuletzt von Crush ]</font>

[Saturo]

YEAH JUHU! DANKE! Ich hab´s gewusst, dass mir hier einer hilft*grins *.

Das problem war:

CString buffer;

m_Eingabe.GetWindowText(buffer);

m_Ausgabe.SetWindowText((LPCSTR)buffer);

m_Ausgabe war ne Membervariable -control

und m_Eingabe war jedoch -string

jetzt zeigt er an, dass Getwindowtext kein Element von string ist...ich habe daraufhin aus m_Eingabe einfach ein control gemacht und nun geht es!!!uahhhhhh!!!

Es ist schon echt unglaublich wie kompliziert einem die Dinge in Sachen Dialoge gemacht werden. Ich habe mich mit visual c++ eigentlich schon lange beschäftigt, habe sogar schon ein kleines opengl programm geschrieben mit objekteditor...aber vor diesen Dialogen und der MFc habe ich mich immer gedrückt...2 Gründe: 1. schien mir alles sehr kompliziert und 2. wollte ich mich nicht so auf microsoft vernarren. hm, kompliziert ist es immer noch. Was mich stört: Die ganzen Abläufe der MFC sind richtig fies versteckt..für mich wirkt es dann unüberschaubar wenn auf einmal irgendwas mit AFX aus dem nichts auftaucht . Ok, aber warscheinlihc checke ich es nur noch nicht so gut.

Vor ein paar Tagen habe ich zum 1.mal mit Visual Basic programmiert. Und ich habe eben diese Anwendung binnen 7 Stunden auf die Reihe gebracht...ohne Vorkenntnisse in Basic. Wenn es sich also nur um Windows-Dialog-Click Anwendungen ohne Grafik handelt, scheint mir VB echt die bessere Alternative zu sein...oder Delphi. Wird es komplizierter...grafischer...dann führt wohl kein Weg um C herum.

Ich bin FISI-AZUBI und mich wurmt es jetzt schon gewaltig: wir bekommen VB und Java-Kurse während die FIAEs C lernen...was soll der Mist? Ok, VB,ok. Aber wir verschwenden 1 Lehrjahr mit Java! Da würde genug Platz für ein fundiertes C-Wissen dasein!

Darum jetzt noch eine Frage an dich, Crush:

Was zum Teufel kann ich mit Java, was ich mit Visual C++ nicht kann? Ist es mit C wirklich unmöglich Applets zu erstellen?

also, nochmal thx und bye!

[mst]

<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica, sans-serif">Zitat:</font><HR>Original erstellt von Saturo:

Was zum Teufel kann ich mit Java, was ich mit Visual C++ nicht kann? Ist es mit C wirklich unmöglich Applets zu erstellen?

[Crush]

Das Problem lag aber nicht nur daran, daß die Typen auseinanderliefen, meine ich. Sondern vor allem, weil halt die Item-Geschichte nicht so funktioniert, wie sie funktionieren soll mit den Edit-Feldern. Erstelle Listen und schon klappen die Item-Zugriffe einwandfrei.

Applets kann man natürlich nicht in C++ machen, aber Du kannst ja eine Exe-rüberschicken und starten lassen ;-D

[Saturo]

wobei wir wieder beim Virusproblem wären und keiner so blöd ist, sich eine exe schicken zu lassen . Somit haben wir jedoch mal wenigstens einen handfesten Vorteil von java...aber kann ich mit javaScript nicht vieles erreichen, wozu ich sonst Java bräuchte?

Ich finde es ist für eine Firmenhomepage ein extremer Nachteil ein Java applet bereitzustellen...1. lange Ladezeiten...2. haben nicht alle Java/aktiviert. Einzig für Webshops vielleicht wäre es sinnvoll..und deshalb soll ich das jetzt lernen???? Wäre es für einen Systemintegrator nicht viel nützlicher eine grundlegende Basissprache wie c zu erlernen? Denn wenn ich C mit seinen Pointern und den Klassen beherrsche, dann dürfte mir ja Java keine großen Probleme mehr bereiten. Für die Homepageverschönerung ist doch Flash bei weitem geeigneter.-meine Meinung