3. Zeigerproblem (kein Compilerfehler) in QtÜbung [close]

Zeigerproblem (kein Compilerfehler) in QtÜbung [close]

  • A

    wit schrieb:

    ...denn laut dem Erklärer dauert Allokieren auf Heap deutlich länger als auf den Stack, ich aber dachte bis jetzt immer, dass wenn ich den Zeiger öfter brauche als einmal und ich so die Klasse immer wieder neu auf dem Stack allokieren muss aufgrund von endenden Namespaces es mit Zeigern dann schon schneller geht???

    Häääh? Entweder ist deine Beschreibung einfach wirr oder schlicht unsinnig.

    Grundsätzlich ist eine Variable auf dem Stack in der Regel vorzuziehen (und etwas schneller), aber es kommt auch immer darauf an was man erreichen will. Wenn ein Objekt über einen Scope (nicht Namespace, das ist etwas ganz anderes) hinweg überdauern muss, so eignet sich eine Stackvariable nicht. Allgemein würde ich sagen: verwende eine Stackvariable immer wenn es geht, und sonst Heapvariablen.

    Nun lässt sich aus deiner Beschreibung aber nicht ablesen was du eigentlich sagen willst.

    0
  • G

    pumuckl schrieb:

    Gero_Programmierstil_de schrieb:

    nenn die dateien besser genau exakt so, wie die klassen heissen, also auch gross/klein-schreibung,etc. hier vlt ein denkanstoss:

    Das ist reine Konventionssache und sonst ziemlich irrelevant. Man sollte es nur einheitlich machen, damit keine Verwirrung entsteht. Ob die Dateien jetzt der Groß-/Kleinschreibung der Klassen folgen oder nicht, ob Header nun mit .h oder .hpp enden usw., ist von Projekt zu Projekt unterschiedlich. Für privaten Gebrauch sollte man sich angewöhnen, womit man selbst am Besten zurecht kommt - da gibts keine Vorgaben.

    (Anders ist das mit der Rechtschreibung...)

    Joaaaa, allerdings sind doch folgende konventionen am weitverbreitesten, oder?
    * dateinamen exakt so benennen wie die enthaltenden klassen.
    * KlassenName.hpp, wenn sich um eine template-klasse handelt, ansonsten KlassenName.h

    (hachja, ich hab den hans ja trotzdem lieb .oO)

    @wit:
    hau mal alles was du jetzt in den konstruktoren hast in jeweils eine zusätzliche init() methode.
    dann kannst du die konstruktoren aufrufen, ohne das jemals irgentwas schief geht, dannach versuch ma, den konstruktor so umzubauen wie in meinen voherigen post.
    dann kannst du erst die objekte erzeugen mittels new(), dann ham sie auch alle jeweils ihre zeiger richtig gesetzt, und erst dannach rufst du jeweils die init()'s auf.
    weisst du, was ich meine?

    0
  • G

    asc schrieb:

    wit schrieb:

    ...denn laut dem Erklärer dauert Allokieren auf Heap deutlich länger als auf den Stack, ich aber dachte bis jetzt immer, dass wenn ich den Zeiger öfter brauche als einmal und ich so die Klasse immer wieder neu auf dem Stack allokieren muss aufgrund von endenden Namespaces es mit Zeigern dann schon schneller geht???

    Häääh? Entweder ist deine Beschreibung einfach wirr oder schlicht unsinnig.

    Grundsätzlich ist eine Variable auf dem Stack in der Regel vorzuziehen (und etwas schneller), aber es kommt auch immer darauf an was man erreichen will. Wenn ein Objekt über einen Scope (nicht Namespace, das ist etwas ganz anderes) hinweg überdauern muss, so eignet sich eine Stackvariable nicht. Allgemein würde ich sagen: verwende eine Stackvariable immer wenn es geht, und sonst Heapvariablen.

    Nun lässt sich aus deiner Beschreibung aber nicht ablesen was du eigentlich sagen willst.

    joa die sätze sind en bisel unsinnig, aber ich glaub, wit meint folgendes:
    er braucht in den klassen ja nicht ein komplettes objekt der anderen klassen, sondern halt jeweils nur einen zeiger. die schlussfolgerung, die objekte auf dem heap (oder auf dem stack, besser halt: überhaupt) zu kreieren, is allerdings falsch, die objekte brauchen jeweils nur zeiger, keine kompletten objekte, weder auf dem stack noch auf den heap.

    zusätzlich zu der bedingung mit "scope überdaeuern" für heap speicher kommt btw noch der fall hinzu, dass man nicht genau weiss, wie groß die variable is, die man braucht.

    0
  • P

    Gero_Programmierstil_de schrieb:

    Joaaaa, allerdings sind doch folgende konventionen am weitverbreitesten, oder?
    * dateinamen exakt so benennen wie die enthaltenden klassen.
    * KlassenName.hpp, wenn sich um eine template-klasse handelt, ansonsten KlassenName.h

    Wäre mir unbekannt, dass die allzu verbreitet sind, geschweige denn weitverbreitet. Dateinamen im CamelCase kenne ich eigentlich nur aus Java, die .hpp/.h-Mix-Regel ist mir ehrlich gesagt noch nie untergekommen. Hast du irgendeine Quelle für diese Konventionen, am Besten mit Statistiken, die zeigen, wie häufig sie vorkommen? Nach allem, was ich bisher in verschiedenen Projekten und Beispielen (online und in Büchern) sehen konnte, sind Konventionen einfach unterschiedlich, einige etwas öfter vertreten als andere, aber keine so prominent, dass man sie jetzt als die allgemeingültige Konvention verkaufen könnte.
    Ich wollte Hans eigentlich schön in seiner Ecke lassen, hab mich nur gewundert, dass jemand mit einem etwas "schnoddrigen" Schreibstil so penibel bei so unwichtigen Dingen wie der Schreibweise von Sourcedateinamen ist 😉

    0
  • A

    pumuckl schrieb:

    Gero_Programmierstil_de schrieb:

    Joaaaa, allerdings sind doch folgende konventionen am weitverbreitesten, oder?
    * dateinamen exakt so benennen wie die enthaltenden klassen.
    * KlassenName.hpp, wenn sich um eine template-klasse handelt, ansonsten KlassenName.h

    Wäre mir unbekannt, dass die allzu verbreitet sind, geschweige denn weitverbreitet.

    Also die erste Regel kenne ich definitiv auch so, und wurde in der Regel so auch an allen Firmen, bei denen ich tätig war gehandhabt (Alles Firmen die hauptsächlich im MS-Umfeld tätig waren, die Hälfte davon rein auf C++ Basis). Auch in einigen Büchern wurde diese Notation verwendet (aber nicht explizit erwähnt). Ich würde sie zumindest zu einer nicht ganz unüblichen Regel zählen, aber ob sie sehr häufig ist steht auch auf einem anderen Blatt..

    Die zweite Regel ist mir wiederum noch nie über den Weg gelaufen (Weder in Büchern noch irgendwo sonst).

    Im wesentlichen ist es aber völlig egal wie eine Benennung erfolgt, und welche Regeln man sich selbst gibt, sofern sie konsistent sind. Wie hat auch schon Herb Sutter und Andrei Alexandrescru so passend geschrieben:

    Buch: C++ Coding Standards schrieb:

    0. Don't sweat the small stuff. (Or: Know what not to standarize)
    ...
    Don't overlegislate naming, but do use a consistent naming convention:
    ...

    0
  • G

    Ich wollte Hans eigentlich schön in seiner Ecke lassen, hab mich nur gewundert, dass jemand mit einem etwas "schnoddrigen" Schreibstil so penibel bei so unwichtigen Dingen wie der Schreibweise von Sourcedateinamen ist 😉

    haha, gut gekontert ;).

    pumuckl schrieb:

    Gero_Programmierstil_de schrieb:

    Joaaaa, allerdings sind doch folgende konventionen am weitverbreitesten, oder?
    * dateinamen exakt so benennen wie die enthaltenden klassen.
    * KlassenName.hpp, wenn sich um eine template-klasse handelt, ansonsten KlassenName.h

    Wäre mir unbekannt, dass die allzu verbreitet sind, geschweige denn weitverbreitet. Dateinamen im CamelCase kenne ich eigentlich nur aus Java, die .hpp/.h-Mix-Regel ist mir ehrlich gesagt noch nie untergekommen. Hast du irgendeine Quelle für diese Konventionen, am Besten mit Statistiken, die zeigen, wie häufig sie vorkommen? Nach allem, was ich bisher in verschiedenen Projekten und Beispielen (online und in Büchern) sehen konnte, sind Konventionen einfach unterschiedlich, einige etwas öfter vertreten als andere, aber keine so prominent, dass man sie jetzt als die allgemeingültige Konvention verkaufen könnte.

    ja würde mich jetz auch genauer interessieren.

    ich forsch mal nen bisschen nach.

    zu der .h/.hpp-geschichte liefer ich mal nen erklärungs-ansatz:
    ich kenns von *.hpp datein halt so, dass sie nicht nur deklarationen enthalten, sondern auch defintionen oder besser gesagt: echten programm-code.
    bei templates is halt genau das oft der fall.
    erst die nutzung eines templates definiert es ja wirklich komplett (jetzt default-spezialiserungen,etc.. ma ausgenommen). bindet man ein template ein und nutz es nicht, entsteht auch kein echter programm-code.

    und wenn man sich die endung jetz ma anguckt:
    *.hpp

    1. ist irgentwie ne vermischung aus *.cpp (code) und *.h (header).
    code + header
    -> templates? könnte sinn machen.

    2. kann man natürlich auch sehen als:
    pp-header
    -> C++ header.
    dann fände ich es aber auch sinnvoll grundsätzlich folgende paarungen zu verwenden: .hpp/.cpp für c++ code und .h/.c für c.

    kann man natürlich anders sehen. was meinst du?

    0
  • A

    Gero_Programmierstil_de schrieb:

    und wenn man sich die endung jetz ma anguckt:
    *.hpp

    1. ist irgentwie ne vermischung aus *.cpp (code) und *.h (header).

    Und wird von einigen Softwareunternehmen und Entwicklern auch als Header für C++ Source verwendet (ist mir u.a. bei Firmen begegnet die sowohl C als auch C++ gleichzeitig im Projekt verwenden, und eine striktere Trennung haben wollten). Ebenso wirst du hpp u.a. im C++ Builder Umfeld recht häufig bei Komponentenheadern finden.

    Ich würde die Kirche daher im Dorf lassen und nicht weitere Konventionen einführen. Wichtig ist wie gesagt eigentlich nur das man einheitlich bleibt.

    Wenn man beruflich mit Programmierung zu tun hat und nicht nur bei einer Firma bleibt, wird man ohnehin immer wieder mit anderen Konventionen für Projekten zu tun haben. Teilweise hat jedes Projekt in einer Firma wieder abweichende Konventionen.

    0
  • P

    Gero_Programmierstil_de schrieb:

    kann man natürlich anders sehen. was meinst du?

    • boost hat afaik ausschließlich .hpp, egal was drin steht (ok, ist zu geschätzten 99,9% eh alles Template-Kram). Klassennamen und Header folgen beide Underscore-Konvention.
    • Bei SFML (weniger templates) scheinen es auch nur .hpp's zu sein, Klassennamen und Header im CamelCase
    • wxWidgets benutzt dagegen nur .h, Klassennamen als wxCamelCase, Headernamen als wx/lowercase.h
    • Ich benutze persönlich auch .cpp und .h, Klassennamen im CamelCase, Header im lowercase. .hpp benutze ich nur sehr selten, wenn ich z.B. einen boost-Header für meine Bedürfnisse modifizieren muss und diese modifizierte Kopie irgendwo bei mir unterbringe. In dem Fall behalte ich auch Schreibweisen für Klassen und Header bei.
    • Auf der Arbeit haben wir hauptsächlich .h, .c, weil unsere Codebase "organisch" gewachsen ist, im Original C war und bei der Umstellung einfach nur der Hebel am Compiler von C auf C++ umgelegt wurde. Neuere Dinge heißen häufig .cpp und .hpp, meistens heißt das im Klartext: ".h/.c" -> ursprünglich C-Code, der mit dem einen oder anderen C++-Feature notdürftig gepimpt wurde. ".cpp/.hpp" -> ursprünglicher C++-Code, bei dem man sich Mühe gegeben hat, objektorientiert zu arbeiten. Häufig auch C mit Klassen und ähnliches. Namen sind ähnlich gemischt, System gibts wenn man Glück hat immerhin innerhalb der einzelnen Module.

    Andere habe ich gerade nicht zur Hand, aber ich denke man darf sich auf Regel 0 von Sutter/Alexandrescu einigen. Ist wahrscheinlich ein ähnlich müßiges Thema wie Klammersetzung und Tab/Einzugsgröße 😉 Hauptsache es bleibt lesbar.

    0
  • G

    Gutes Schlusswort dazu.

    B2T: wit, weitergekommen?

    0
  • W

    ich bin grad erst heimgekommen und konnte folglich nicht weitermachen...
    hmm, eigentlich habe ich was anderes mit meiner Frage gemeint, aber irgendwie ist sie schwachsinnig umso länger ich darüber nachdenke

    @gero: Ich glaube ich habe verstanden was du meinst, aber ich verstehe den Sinn nicht so ganz 😞 Könntest du es mir bitte nochmal erklären?

    Edit: Ich mach jetzt erstmal alles in forward declarationen, bin vohin nimmer dazu gekommen...
    Edit2: Obwohl was du mit der init methode meinst habe ich doch noch nicht gerafft... Sowas wie auf der 1 Seite, dumm frag
    Edit 3: Das mit den Namen kann ich jetzt nimmer ändern werde ich aber in Zukunft machen
    Desweiteren wollte ich noch sagen, auch wenn ihr das über gero amüsant findet, das ich sehr froh bin das er mir soetwas wie z.B. solche Namensgeschichten sagt, weil ich ja wie gesagt niemanden kenne

    0
  • W

    grml, also das mit dem schnell ins forward declarationen umwandeln hat schon mal nicht geklappt *rofl
    aber jetzt wart ich mal den morgigen Tag ab, hab ja schon bissel was intus 😃

    Edit: Hat jetzt doch funktioniert war nur zu blöd
    Edit2: Wow, compiliert der jetzt schneller, das der Unterschied so groß ist hätte ich nicht gedacht 🙂

    0
  • W

    So und weil ich grad eh schon am spamen bin, übersetze ich das richtig im Kontext?

    0. Don't sweat the small stuff.
    Mach dir keine Sorger über die unwichtigen Sachen?

    Don't overlegislate naming, but do use a consistent naming convention:
    und hier was heißt das Wort "overlegislate"? - übertreiben?

    Hoffe ich nerv euch nicht zu sehr 🙄 aber wenn will ich schon alles wissen 😉

    0
  • P

    wit schrieb:

    0. Don't sweat the small stuff.
    Mach dir keine Sorger über die unwichtigen Sachen?

    So in der Art - "mach dir keinen Kopf um Kleinigkeiten" würds auch treffen.

    Don't overlegislate naming, but do use a consistent naming convention:
    und hier was heißt das Wort "overlegislate"? - übertreiben?

    overlegislate = zusammengesetzt over und legislate* -> nicht übermäßig reglementieren.

    ______________________
    *siehe auch dt. Legislative = Gesetzgebung, von lat. lex/legis: das Gesetz => nicht als Klugscheißerei gemeint, aber oft kann man sich unbekannte Vokabeln aus Fremdwörtern oder lang vergangenen Lateinstunden herleiten 😉

    0
  • W

    danke

    pumuckl schrieb:

    ______________________
    *siehe auch dt. Legislative = Gesetzgebung, von lat. lex/legis: das Gesetz => nicht als Klugscheißerei gemeint, aber oft kann man sich unbekannte Vokabeln aus Fremdwörtern oder lang vergangenen Lateinstunden herleiten 😉

    hab kein Larain... und dass das nicht als Klugscheißer gemeint ist, ist mir klar da braucht man sich bei mir keine Sorgen machen, kenne auch ein paar sehr intelligente Leute im Vergleich zu mir 😃

    Edit: Außerdem hätte ich dann nicht gefragt 😉

    0
  • W

    Gero_Programmierstil_de schrieb:

    joa die sätze sind en bisel unsinnig, aber ich glaub, wit meint folgendes:
    er braucht in den klassen ja nicht ein komplettes objekt der anderen klassen, sondern halt jeweils nur einen zeiger. die schlussfolgerung, die objekte auf dem heap (oder auf dem stack, besser halt: überhaupt) zu kreieren, is allerdings falsch, die objekte brauchen jeweils nur zeiger, keine kompletten objekte, weder auf dem stack noch auf den heap.

    Mir ist grad noch eine Frage aufgekommen, auch wenn ich das in dem Fall nicht das gemeint hab... Fakt ist, aber ich hab aber mehr oder weniger so gedacht und vertehe jetzt noch nicht ganz warum die Schlussfolgerung jetzt falsch ist?

    0
  • W

    So ich hab jetzt noch ein bissel gebastelt und habe wie in deinem Beispiel im Konstruktor einen Zeiger deklariert...
    aber was meinst du mit der initmethode?
    und wo soll ich den Zeiger aus dem Konstruktor dann initialisieren?

    0
  • W

    it doesnt work!! 😞
    Ich hab jetzt mal so versucht wie du gesagt hast ohne Erfolg + Compilerfehler

    Das habe ich jetzt gemacht...

    Registration.h

    #ifndef REGISTRATION_H
#define REGISTRATION_H

#include <QDialog>
#include "ui_registration.h"

class Check;
class Startfenster;

class Registration : public QDialog
{
    Q_OBJECT

public:
    explicit Registration(Startfenster *inStart, Check *inCheck, QWidget *parent = 0);
    ~Registration();

private slots:
    void setUpS();
    void setUpC();

public:
    Ui::Registration *ui;

    Startfenster *Startm;
    Check *Che;

    void ini();
};

#endif // REGISTRATION_H

    Registration.cpp

    ...
Registration::Registration(Startfenster *inStart, Check *inCheck, QWidget *parent = 0) :
    QDialog(parent),
    ui(new Ui::Registration)
{
    ui->setupUi(this);

    this->Startm = inStart;
    this->Che = inCheck;

    ini();
}

...

void Registration::ini()
{
    connect(ui->Zurueck, SIGNAL(clicked()), this, SLOT(setUpS()));
    connect(ui->Weiter, SIGNAL(clicked()), this, SLOT(setUpC()));

    //Werte übergeben
    connect(ui->Vorname, SIGNAL(textChanged(QString)), Che->ui->Vorname, SLOT(setText(QString)));
...
}

void Registration::setUpC()
{
    Che->show();
    Che->raise();
    Che->activateWindow();
}

...

    main.cpp

    ...
int main(int argc, char *argv[])
{
    QApplication app(argc, argv);

    Startfenster *inStart = new Startfenster;
    Registration *inRegis = new Registration;
    Check *inCheck = new Check;

    class Startfenster start(*inRegis);
    class Registration registratio(*inStart, *inCheck);
    class chec(*inRegis);

    start.show();

    return app.exec();
}

    Compilerfehler:
    main.cpp:12: error: no matching function for call to 'Startfenster::Startfenster()'
    startfenster.h:14: note: candidates are: Startfenster::Startfenster(Registration*, QWidget*)
    startfenster.h:10: note: Startfenster::Startfenster(const Startfenster&)
    main.cpp:13: error: no matching function for call to 'Registration::Registration()'
    registration.h:18: note: candidates are: Registration::Registration(Startfenster*, Check*, QWidget*)
    registration.h:11: note: Registration::Registration(const Registration&)
    main.cpp:14: error: no matching function for call to 'Check::Check()'
    Check.h:16: note: candidates are: Check::Check(Registration*, QWidget*)
    check.h:10: note: Check::Check(const Check&)
    main.cpp:16: error: no matching function for call to 'Startfenster::Startfenster(Registration&)'
    startfenster.h:14: note: candidates are: Startfenster::Startfenster(Registration*, QWidget*)
    startfenster.h:10: note: Startfenster::Startfenster(const Startfenster&)
    main.cpp:17: error: no matching function for call to 'Registration::Registration(Startfenster&, Check&)'
    registration.h:18: note: candidates are: Registration::Registration(Startfenster*, Check*, QWidget*)
    registration.h:11: note: Registration::Registration(const Registration&)
    main.cpp:18: error: conflicting declaration 'chec* inRegis'
    main.cpp:13: error: 'inRegis' has a previous declaration as 'Registration* inRegis'

    Bitte um weitere Hilfe der Experten

    Edit: War das jetzt eigl. was du gemeint hast, gero?

    0
  • G

    geht schon in die richtige richtung.
    hier ist erstmal nur kurz der korrigierte code:

    Registration.h

    #ifndef REGISTRATION_H
#define REGISTRATION_H

#include <QDialog>
#include "ui_registration.h"

class Check;
class Startfenster;

class Registration : public QDialog
{
    Q_OBJECT

public:
    explicit Registration(Startfenster *inStart, Check *inCheck, QWidget *parent = 0);
    ~Registration();

public:
    void init(); // << ist jetz hier explizit als public deklariert

private slots:
    void setUpS();
    void setUpC();

private: // << die funktion init() soll public werden, die member-variablen sollen aber pivate bleiben.
    Ui::Registration *ui;

    Startfenster *Startm;
    Check *Che;

};

#endif // REGISTRATION_H

    Registration.cpp

    ...
Registration::Registration(Startfenster *inStart, Check *inCheck, QWidget *parent = 0) :
    QDialog(parent),
    ui(new Ui::Registration),

    // !!! wichtig, dein code war auch richtig, aber so ist besser (guck dir vielleicht mal an, was initialisierungs-listen sind.
    Startm(inStart), 
    Che(inCheck)
{
  // egal was jetz hier noch passiert, Startm und Che sind schon gesetzt.

    ui->setupUi(this); // <<< ich weiss von qt leider zu wenig, aber vielleicht macht es sinn, diese zeile auch mit in die init() methode rüberzuziehen.

// !!! wichtig
//    init(); //<< init() nicht hier im konstruktor aufrufen, das is wichtig
/// init() haben wir eingeführt, damit das wirkliche echte initialiseren GERADE NICHT vom konstruktor gemacht wird. eine gute merk-regel ist: im konstruktor sollten grundsätzlich nur sachen gemacht werden, die auf gar keinen fall schief gehen können.
}

...

// hier kannst du nun rumhuren, mit allen was verfügbar ist ;)
void Registration::init()
{
    connect(ui->Zurueck, SIGNAL(clicked()), this, SLOT(setUpS()));
    connect(ui->Weiter, SIGNAL(clicked()), this, SLOT(setUpC()));

    //Werte übergeben
    connect(ui->Vorname, SIGNAL(textChanged(QString)), Che->ui->Vorname, SLOT(setText(QString)));
...
}

void Registration::setUpC()
{
    Che->show();
    Che->raise();
    Che->activateWindow();
}

...

    main.cpp

    ...
int main(int argc, char *argv[])
{
    QApplication app(argc, argv);

    // !!!! das hier ist auch wichtig:

    // erst werden objekte der klasse Check un Startfenster instantiert:
    Check *check = new Check();
    Startfenster *start = new Startfenster();

    // diese werden nun an den konstruktor von Registration übergeben:
    Registration *regis = new Registration(start , check /*, 0 */); // < die 0 für QWidget *parent fügt der compiler aufomatisch hinzu, wegen default-argument (=0). das hattest du ja schon verstanden...

    // das folgende is unsinng:
//    class Startfenster start(*inRegis);
//    class Registration registratio(*inStart, *inCheck);
//    class chec(*inRegis);

    // folgendes ist von mir hinzugefügt und wieder wichtig:
    regis->init() // <<< init() method wird aufgerufen

    start.show();

    return app.exec();
}
    0
  • W

    ok, dann änder ich das mal und lese in meinem Buch nochmal Initialisierungslisten nach... Kann aber sein das ich mich erst übermorgen melde ob es funktioniert, da ich jetzt dann Besuch kriege 😉
    Das mit dem setupUi lass ich lieber, weil mit Qt habe ich jetzt erst vor einem halben Jahr angefangen und weiß folglich noch weniger als in C++ 😞 und ich möchte jetzt lieber nicht noch nen QtExperten von euch vollnerven...

    0
  • W

    habe jetzt noch geschafft, die Fehler auszubessern, habe aber leider neue Fehler bekommen während ich den Ersten noch lösen konnte 🙂
    funktioniert irgendetwas mit deiner Initialisierungsliste nicht...

    meine main sieht jetzt so aus:

    ...
class Registration *Regis;

int main(int argc, char *argv[])
{
    QApplication app(argc, argv);

    Startfenster *Start = new Startfenster(Regis);
    Check *check = new Check(Regis);
    Registration *Regis = new Registration(Start, check);

    Start->ini();
    Regis->ini();
    check->ini();

    Start->show();
...

    Fehler ist folgender: startfenster.cpp:10: error: '((Startfenster*)this)->Startfenster::Regi' cannot be used as a function
    sieht genau wie in deinem Post aus, außer das ich das setupUi gelassen habe

    Noch eine Frage in den richtigen Programmen sind dann die init-Dataien was wir jetzt als Funktion gemacht haben?

    0
Anmelden zum Antworten