Zugriff auf QLineEdit verursacht Absturz

[RHBaum]

denke mal der Name ist nur Bescheuert gewählt
Das ding soll sicher CounterWidget heissen ....

Wobei die vererbung alles andere als gerechtfertigt ist ^^

wie Braunstein schon andeutet, nur weil ein Gui-Object ein LineEdit beinhaltet, bedient was auch immer, ist noch lange keine vererbung gerechtfertigt.

Vererben tut man ausschließlich, wenn man jemand anderes (ner library, nem Kumpel, dem eigenenen code ) seine Eigene Klasse als die Klasse verkaufen will, von der man abgeleitet hat.
Derjenige sollte dann gar ned wissen, was er da wirklich hat ...
Mal vereinfacht ausgedrueckt ^^

Und wenn man an protected Member und Methoden rankommen will/muss ... aber das ne andere Schiene ...

noch was ....

QPushButton *cl, *plus; //, *finito;
QWidget *fen;

Zeiger auf Klassen als Member sind ne recht "harte" Abhängigkeit ...
bei allen C++ technischen Nachteilen die die Qt mit sich bringt, mit selfdestroy und so weiter ... ist der gravierende Vorteil die viel losere Kopplung über Signal/Slot Ebene !!!
Also lieber die SubElemente lokal in ner Methode Konstruktur erzeugen, und ausschliessliche ueber Signals/Slots verbinden und die dinger dann vergessen (die loeschen sich ja selber wenn der parent stirbt ...)
Das macht den Code robuster und wartungsfreundlicher ...

und 200 mal an die Tafel schreiben: C++ != C, C++ = RAII -> Ressource Aqusition Is Initialisation!

int n;

gehoert initialisiert !

QPushButton *cl, *plus;  //, *finito;
    QWidget *fen;

gehört ebenfalls initialisiert asap! (initialisierungsliste ... wenn man son kram schon braucht. notfalls mit nullptr)

Ciao ...

[Mechanics]

rustyoldguy schrieb:

Besser so?

Ja. So wirklich durchblicken tu ich aber nicht Auf den ersten Blick sehe ich den Fehler nicht. Wenn du sagst, dass der Absturz in testen passiert, scheint die Reihenfolge halbwegs ok zu sein. Erst muss MeinFenster aufgerufen werden, und das erstellt erst den Button und verbindet den mit dem Slot testen, also muss hf schon da sein.
Aber wie gesagt, nur auf den ersten Blick. Der ganze Aufbau ist schon etwas ungewöhnlich und unsicher, da lohnt es sich nicht so, sich den Kopf über irgendwelche Bugs zu zerbrechen Schmeiß den Code weg und versuch das nochmal, das geht sauberer.

[rustyoldguy]

Ich hab das ganze noch mal geschrieben. Diesmal hab ich den QT-Designer verwendet.
Jetzt klappt das ganze.
Eingabe in Altgrad:

degree = (grad -> text()).toDouble();

Ausgabe:

ergebnis  -> setText(QString("%1").arg(sinus,0,'f',7));

Die Kritik mit den Namen möchte ich zu Herzen nehmen. Ich habe die Angewohnheit
das meiste in deutsch zu schreiben, teilweise sogar im bayerischen Dialekt, manchmal auch in französisch. Ich werde versuchen, mich zu bessern.
Nicht das einer noch denkt, ich würde so manchen Leuten Kulturimperialismus im Bezug auf die englische Sprache vorwerfen! Gemach, das sei ferne!

[Mechanics]

rustyoldguy schrieb:

Die Kritik mit den Namen möchte ich zu Herzen nehmen. Ich habe die Angewohnheit
das meiste in deutsch zu schreiben, teilweise sogar im bayerischen Dialekt

Ich habe in dem Beitrag noch nichts dazu gesehen und auch selber nichts gesagt, aber wo du da schon selber erwähnst, ich mag sowas selber überhaupt nicht. Das ist immer inkonsistent und hässlich. Meist läuft es auf komischen Mischmasch wie getWert, holeWert oder sowas hinaus. Und was ist mit Funktionsnamen? führeAus()? ausführen()? Ach ja, Sonderzeichen sind ja meist auch nicht schön, also fuehreAus()? Deutsch ist für sowas einfach nicht geeignet. Und dann benutzt man noch zig 3rd party Bibliotheken, wo alles andere auf Englisch ist, und dann hat man noch mehr Inkonsistenzen. Und es schaut absolut amateurhaft aus.
Ich sehe sowas nur ein, wenn man Spezialsoftware für eine bestimmte Domäne schreibt und die englischen Fachbegriffe nicht kennt und die auch nichts bringen würden. Das kann aber auch in einer eigenen Logikschicht verstecken.

[rustyoldguy]

Das meiste was ich momentan schreibe, ist in englisch, alleine schon
wegen der Nähe zu Linux. Manchmal lassen sich aber andere Sprachen als
Englisch nicht vermeiden, wie etwa bei einem Programm zur Berechnung von Passungen nach DIN ISO 286:

ES und EI bzw. es und ei
das ist französisch und steht für

ecart interieur und ecart superieur

also oberes und unteres Abmaß. Würde ich upper deviation schreiben,
müßte ich das mit UD abkürzen. Aber international hat ich ES/EI für
Einheitsbohrung und es/es für das System Einheitswelle eingebürgert.
Probleme machen dann auch die Nähe mancher Variablen zu Schlüsselwörtern.
Dann muss man eben in den saueren Apfel beissen. sonst, da gebe ich
dir Recht, sind die meisten Bezeichnungen in englisch kürzer als in
deutsch und das ist in Quellcodes wichtig. Die ersten Proggis in QT
laufen. Hat wenig Zeit gekostet sich and den Qt-Designer anzupassen.
Jeder Anfang ist schwer. Der Rest ist Arbeit.

[Mechanics]

rustyoldguy schrieb:

wie etwa bei einem Programm zur Berechnung von Passungen nach DIN ISO 286:

Das meinte ich mit Spezialsoftware für bestimmte Domänen.

[__jb__]

Hi rustyoldguy,
ich würde Dir empfehlen, sich den Qt Designer anzuschauen.
Damit musst Du dann Deine GUI nicht mehr händisch zusammen programmieren, sondern kannst schön im WYSIWYG Editor sie so zusammenbauen, wie Du sie brauchst.
Nur als Randbemerkung.
Viele Grüße,
Jakob

[rustyoldguy]

Das einzige woran ich jetzt noch knabbere, ist dem "Kind" einen richtig
passenden Namen zu geben. Wellenrechner oder Bohrungsrechner sind hier
absolut unpassend. IT-Passungsrechner auch nicht.
Mal gucken, was mir an Namen fürs Proggi noch einfällt.

[rustyoldguy]

Das mit dem QT-Designer hab ich schon spitz gekriegt. Viel schöner, als
wie früher wo man das in nerviger Kleinarbeit alles per Hand eingeben
mußte. Ein sehr schönes Tool!

[Mechanics]

RAD Designer sind nun wirklich nichts neues. Gabs schon in den neunzigern, wenn nicht sogar früher. Natürlich sind die jetzt mächtiger und einfacher zu bedienen, aber wie gesagt nichts grundlegend neues. Und wenn man komplexere GUIs braucht, dann muss man die trotzdem von Hand programmieren. Kann mich nicht erinnern, in den letzten Jahren jemals den Designer verwendet zu haben.