4. QT Kontrolle

QT Kontrolle

  • ?

    Also da ich mir immer noch sehr unsicher bin im Umgang mit slots und Co wäre es nett wenn mir jmd sagen könnte ob das was ich hier geschrieben habe praxistauglich wäre, die Gui wurde mit QT-Designer zusammengklickt.

    #include "mainwindow.h"
#include "ui_mainwindow.h"

#include <QFileDialog>

MainWindow::MainWindow(QWidget *parent)
    : QMainWindow(parent), ui(new Ui::MainWindow)
{
    ui->setupUi(this);

    // SIGNALE
    setupConnections();
}

MainWindow::~MainWindow()
{
    delete ui;
}

// PRIVATE FUNKTIONEN
void MainWindow::setupConnections()
{
    connect(ui->action_oeffnen, SIGNAL(triggered()), this, SLOT(loadFile()));
    connect(ui->Button_LoadFile, SIGNAL(clicked()), this, SLOT(loadFile()));
}

// PUBLIC SLOTS

std::string MainWindow::loadFile()
{
    QString file = QFileDialog::getOpenFileName(this);
    std::cout << file.toStdString() << std::endl;
    return file.toStdString();

}

    meine Hauptfrage ist ob die beiden Connections richtig durchgeführt worden sind, oder ob da Probleme zu erwarten sind.
    Und da ist mein Hauptaugenmekr auf Empfänger gerichtet.

    Über den Sinn/Unsinn des Programms soll noch nicht eingegangen werden, da werde ich später ein anderes Unter-Forum belästigen ^^

    0
  • T

    Hallo,

    deine connects sind richtig geschrieben. Jedoch darf deine Funktion keinen return wert zurück liefern.
    Die Signale sowie die Slots müssen den Rückgabewert void haben. Was du machen kannst sind nur Parameter übergeben. Und bei Parameterübergabe ist darauf zu achten das der Parameter vom signale dem slot identsich übereinstimmt!

    z.B. connect(member, SIGNAL(sende_funktion(int &)), this, SLOT(empfänger_funktion(int &)));

    Gruß
    Tscheburator

    0
  • L

    Tscheburator schrieb:

    deine connects sind richtig geschrieben. Jedoch darf deine Funktion keinen return wert zurück liefern.
    Die Signale sowie die Slots müssen den Rückgabewert void haben.

    Nö.
    SLOTS können sehr wohl Rückgabewerte haben, man kann die nur nicht bei einem Aufruf durch den connect nutzen (wie auch).
    SLOTS sind ganz normale Funktionen!

    Desweiteren: Warum unbedingt an der Stelle schon nen std::string zurückgeben?
    Ich würde da nen QString zurückgeben! Wenn du eine Bibliothek verwendest, die std::string braucht, dann würde ich den QString erst bei der Übergabe an so eine Funktion in einen std::string umwandeln.
    QString ist dank funktionierendem Unicode deutlich flexibler als ein std::string, und vor allem hast du in den ganzen Qt-Libs KEINE (!) Klassen, die nen std::string schlucken (bis auf diejenigen Funktionen in QString zum konvertieren).

    Und zu guter letzt:
    Die beiden connects finde ich überflüssig. Mach nur den einen mit der QAction, als Button nimmst du nen QToolButton (nehme ich an). Da gibt es eine Funktion "setDefaultAction(QAction*)" (ist ein SLOT), damit bekommt der ToolButton gleich das passende ICON und Text usw. Und vor allem reagiert er auch auf den CONNECT mit der QAction.
    Da der Toolbutton aber schon in der ui steht, denke ich ist der toolbutton eh schon mit der action verknüpft. Oder?

    0
  • L

    Tscheburator schrieb:

    Und bei Parameterübergabe ist darauf zu achten das der Parameter vom signale dem slot identsich übereinstimmt!

    Den hab ich ja ganz vergessen 😉
    Auch hier: Nö 😛
    Der SLOT darf weniger Parameter haben, wobei die Parameter von hinten weg entfernt werden müssen.
    Das geht:

    connect(src, SIGNAL(send(const QString&, int)), dest, SLOT(recieve(const QString&)));

    Das nicht:

    connect(src, SIGNAL(send(const QString&, int)), dest, SLOT(recieve(int)));
    0
  • ?

    Ok dann noch einige Fragen:

    Ich brauche zwar die GUI mehr oder weniger als Hauptfenster um Einstellungen zu treffen, aber das Hauptprogramm soll dann in einem anderen Fenster (sfml-RenderWindow) ablaufen.

    Kann ich dann mein Hauptfenster in eine Klasse Programm packen sowas wie

    int Programm::start()
{
    QApplicatin a(0, NULL);
    MainWindow x;
    x.show();
    return x.exec();
}

    und dann auf Knopfdruck ein neues Fenster starten, in der Art

    connect(ui->Button_StartSFML, SIGNAL(clicked()), this, SLOT(startSFML()));

void startSFML()
{
    RenderWindow x(...);
    ...
}

    Kann man das so machen um den Dialog und ein anderes Fenster gleichzeitig ablaufen zu lassen,
    Oder ist das ganze eher anders anzugehen?

    0
  • L

    Du darfst ruhig die SFML-Doku lesen...
    http://www.sfml-dev.org/tutorials/1.5/graphics-qt.php

    0
  • ?

    Der Beitrag ist mir nicht neu, ich möchteallerdings kein qt-canvas, sondern ein unabhängiges renderwindow, das keinerlei anhängigkeit von qt mehr hat.
    Auch kein DockingWindow sondern ein wirklich eigenständiges Fenster ohne Signale von Qt noch sonstiges, SFML soll auch seine eigene Eventschleife haben.

    Ist das dann so möglich wie ich es mir oben denke oder sollte ich zuerst noch den dann nicht mehr nötigen Dialog löschen und beim Schließen des SFML Fensters neu erstellen?

    Also das was Laurent da geschrieben hat ist ja wunderbar aber ich denke ich brauch gar nicht soviel

    0
  • ?

    Also ein erster Probelauf ergab:

    Das SFML-Fenster wird gestartet, nur hängt das QT-Fenster derweil, es nimmt aber noch Events an.

    Gibts es eine Funtion um QT-Fenster "schlafen" zu legen?
    Also das Fenster soll zwar noch sichtbar sein, aber bis auf Verschieben und solche Aktionen nicht mehr reaktionsfähig sein und vor allem keinen Speicher weiter verbrauchen.

    0
Anmelden zum Antworten