Dotaz: QT5 zaslani dat potomkovi; pomocí signálů

[exo]

Ahoj. Můžete mi někdo poradit? Mám aplikaci s hlavním vláknem a vláknem1. V prvním vlákně běží GUI, ve druhém příkazový řádek. Pomocí GUI potřebuji ovlivňovat příkazy které bude příkazový řádek zpracovávat. Existuje nějaká možnost, jak poslat data od předka do potomka? V přdkovi mám signál haveData(QString), ten vyvolam ve chvili, kdy mam pro potomka nejaka data. V potomkovi mam pak slot který má daný signál zachytit a zpracovat. connect(parent, SIGNAL(haveData(QString)), this, SLOT(insertInput(QString))); Jenže ten na signál nereaguje. V konstruktoru dítěte mám na předka odkaz: explicit mcmd(QMainWindow *parent);

Nenapadá mne už co dělám špatně , nicméně je divné, že QTCreator všechny signály při zápisu předbízí/doplňujě, ale v tomto případě ne.

Odpovědi

[Beda0]

Zběžně to vypadá, že parent je QMainWindow, který nezná signál haveData(QString) -  QMainWindow nahradit třídou, která obsahuje ten signál (a dědí z QMainWindow)

[exo]

Díky za tip... nakonec jsem se rozhodnul vytvořit samostatnou třídu na zaslání signálu, kterou jsem předal jak do konstruktoru mého cmd programu, tak do mainwindow.

Signál se již předbízí, opět jsem ale bohužel dopadnul stejně Signál je vyslán, ale cmd jej nezachytí... zkusím uvést příklad...

//*********************
(MainWindow.cpp)
//*********************

...
//Konstruktor
MainWindow::MainWindow(QWidget *parent) :
    QMainWindow(parent),
    ui(new Ui::MainWindow),
    mycommandline(0)
{
    ui->setupUi(this);
    connect(ui->pushButton, SIGNAL(clicked()), this, SLOT(startCommandline()));
    connect(ui->pushButton_2, SIGNAL(clicked()), this, SLOT(executeCommand()));
}

...
void MainWindow::startCommandline()
{

    myiface = new minterface();
    mycommandline = new mcmd(myiface);
    mycommandline->start();                      // spustíme vlákno
}

void MainWindow::executeCommand()
{
    myiface->emitSignal("ping 192.168.1.1");    //nefunguje - vola funkci emit v myiface
    emit myiface->haveData("ping 192.168.1.1"); //taky ne 
}





//*********************
(mcmd.cpp)
//*********************

...
mcmd::mcmd(minterface *parent)
{
    commandline = new QProcess();
    connect(parent, SIGNAL(haveData(QString)), this, SLOT(insertInput(QString)));
}

...
void mcmd::run()
{

    commandline->start("cmd");
    commandline->waitForReadyRead();
}

void mcmd::insertInput(QString m_input)  //sem signal nikdy nedorazi 
{
    input = m_input.toLatin1();
    commandline->write(input);
    commandline->write("\n");
    commandline->waitForReadyRead();
}

void mcmd::getOutput()                   //odeslani odtud do predka funguje bez problemu...
{
    result = commandline->readAll();
    emit sendingData(QString(result));
}

[exo]

Omlouvám se všem. Jsem jelito... funkci insertInput(QString m_input) jsem zapoměl definovat jako slot . Už to něco dělá . Akorát mi teď zamrzává GUI, což znamená, že ještě něco dělám špatně. Ale s tím už se snad nějak porvu...

[Beda0]

Pokud je aplikace jednovláknová, tak pravděpodobně GUI čeká na zbytek aplikace. Sloty/signály samy nezaručí to, že když se vyšlou, tak program běží paralelně na dvou místech. Pokud je vyhozen signál, tak aplikace hledá kde se má přijmout - spustí se kód slotu a až po jeho doběhnutí se zase vrátí na místo odkud byl signál vyslán.

[exo]

Nee. cmdčko se pouští v samostatném vlákně. Tím že jsem udělal samostatnou třídu na výměnu dat minterface() jsem si kupodivu pomohl. (abych si vzájemně neovlivňoval vlákna, vytvořil jsem minterface až v novém vláknu potomka a předal odkaz na něj zpět do předka - ale asi špatně)

GUI se zasekne ve chvíli kdy CMDčku pomocí signálu pošlu další příkaz k vykonání (předchozí příkazy které mu dávám při inicializaci vlákna proběhnout krásně paralelně...).

Pak začne aplikace hlásit něco o probému s thready, že se cmd pouští v jiném vlákně a celé to zatuhne... Ještě s tím budu chvílku bojovat a pokud se mi to nepodaří tak se vás tu zkusím znovu zeptat. Beztak to bude zase nějaká úplná bobost .

[MadCatX]

A máte ta vlákna udělaná dobře? V Qt nelze jen zdědit z třídy QThread, jako se to dělá třeba v Javě.

[Ivan]

Ono to "jde" akorat se to "nedoporucuje". I kdyz vlastne dokumentace to porad jeste "doporucuje".

Zkuste zadat do google "qthread you're doing it wrong" and "qthread You were not doing so wrong". Tyhle clanky nastini oba pristupy. Vami zminovany clanek jsem kdysi pouzil a a trochu rozsiril:

toEventQuery toEventQueryWorker

Pridal jsem zniceni vlakna i parent objektu a asynchronni preruseni cinnosti bg vlakna.

[MadCatX]

Ano, v Qt je to dost nešťastně zmatené. Z různých zdrojů jsem pochopil, že subclassovat QThread a overridnout run() je možné tehdy, pokud nepotřebujete v daném vlákně zpracovávat eventy. Na jednorázovou akci (zápis do DB, složitější výpočet) to funguje dobře. Z toho, co ale tazatel píše soudím, že chce v GUI vlákně odpálit nějaký signál a příslušnou akci provést ve vlákně jiném. V takovém případě je vhodné použít QThread + Worker řešení. Další hezký zápisek rozebírající různé možnosti a jejich funkci je třeba zde (http://blog.debao.me/2013/08/how-to-use-qthread-in-the-right-way-part-1/)

Pokud máte zájem, můžu postnout nějaký jednoduchý příklad, jak to lze vyřešit, až se dostanu domů...

[exo]

Ahoj. no... jinak řečeno, potřebuju vytvořit něco jako CMD simulátor. Prostě z gui potřebuju spouštět a řídit cmd příkazy. V případě jednoduchého a neměnného zadání není problém. Například pusť ping na 192.168.1.1. Zinicializuji nové vlákno a v něm vše vytvořím a spustím. Pokud ale dojde na to že potřebuji zadání měnit, už narážím na problém. A to vůbec nemluvím o tom, když potřebuji spustit příkaz, ktarý v půlce potřebuje uživatelskou interakci. Například "net use" který se v průběhu dotáže na heslo, nebo kopírování, které narazí na "je cílové umístění soubor nebo adresář?"

V té chvíli potřebuji mít a) nezakousnuté gui b) možnost poslat mému cmd další znaky aby mohl pokračovat. Ono a) by možná nevadilo, jenže já chci mít gui ve chvíli provádění příkazu živé. Očekávám že uživatel... než se vyhodnotí příkaz může dělat něco jiného.

Takže cílem je spustit příkaz a pracovat na něčem jiném. Mezi tím se bude v nějakém textboxu vypisovat výstup. Jakmile se cmd zasatví, buď že už příkaz doběhnul a nebo čeká na doplnění informací, pošlu mu další znaky a opět pokračuju v práci.

Teď na to nebudu mít zhruba týden čas určitě se ale k problému co nejdříve vrátím a dám info jak se mi podařilo pokročit.

Jak popisuju, připadalo mi logické vytvořit třídu hlavního okna, třídu interface a třídu cmd. V hlavním okně standardně pracuju a v jiném thredu inicializuji cmd. Do cmd pak potřebuju prlběžně zasílat příkazy a z něj vracet odezvu bez toho, aby mi zamrzlo GUI. Toť mým hlavním cílem .

Pokud by jste k tomu měli ještě nějaké rady či nápady určitě za ně budu rád. Ty odkazy ještě určitě nastuduju.

[Ivan]

hmm docela zajimava uloha. takovy veci jako alokace pts a emulace terminalu (vt100) uz mas poreseny? to mi prijde jako slozitejsi problem nez ty vlakna. Zkus se podivat na libqterminal

[skunkOS]

Zmatené není v podstatě nic, jen dokumentace na několika místech. Prakticky NIKDY se QThread nemusí a nemá dědit, worker řešení se naopak má použít skoro vždy.

Máme tu taky QtConcurrent::run(...) metodu, která se tazateli může hodit.

http://qt-project.org/doc/qt-4.8/qtconcurrent.html

[Petr Bravenec]

Zmatené není v podstatě nic, jen dokumentace na několika místech.

Souhlas

Prakticky NIKDY se QThread nemusí dědit...

Souhlas

...a nemá dědit

Pověra

worker řešení se naopak má použít skoro vždy

Pověra

Abych nebyl tak úsečný - worker-like řešení s děděním QThread může fungovat stejně dobře a mít některé jiné výhody, například to, že inicializace a start vlákna se přesune z hlavního vlákna, kde "zavazí", někam jinam, kde lépe ctí princip zapouzdřenosti objektu. Shrnul bych to spíš do jiné věty:

Přetěžovat QThread::run() je hloupost.

[Petr Bravenec]

Pročetl jsem si tady tu diskusi. Možná se úplně pletu, když tak mě opravte.

Vlákna si můžete dělat jak chcete - neexistuje "špatná" nebo "dobrá" cesta. Články jako "you are doing it wrong" a "you are not doing it not so wrong" vám řeknou každý něco jiného. Kdejaká *jednovláknová* aplikace v Qt používá při svém běhu spousty různých vláken a když se nad tím zamyslím, vychází mi z toho, že samotné Qt to dělá "wrong" (nebo "not so wrong"?) - a funguje to.

Teď možná kecám, ale nebudu to ověřovat - pokud posíláte signál z vlákna A do slotu ve vlákně B, slot je překvapivě prováděn ve vlákně A. Ověřit si to můžete celkem jednoduše: qDebug() << QThread::currentThread(); . To může vést k hodně velikému zmatení. Řešením je posílat signál přes frontu zpráv, například:

connect(this, SIGNAL(sig1()), vlakno, SLOT(slot1()), Qt::QueuedConnection);

Vede to občas k trochu pracnějšímu zápisu: z GUI volám slot ve vlákně a až tam vyvolám signál přes frontu propojený s jiným slotem ve vlákně. Pokud to takhle nefunguje, budu muset svůj přístup přehodnotit a přepsat nějaké aplikace

S vlákny v Qt není moc problémů při vytváření a používání. Ovšem na hotové peklo můžete narazit, až budete chtít vlákno ukončit. Potíž může být i v tom, že u spousty Qt objektů ani netušíte, že si startují vlastní vlákna (QNetworkAccessManager).

[Petr Bravenec]

Pečlivě jsem si prostudoval výše uvedený odkaz: http://blog.debao.me/2013/08/how-to-use-qthread-in-the-right-way-part-1/

Lépe shrnutou problematiku vláken v Qt jsem dosud nečetl. Budu muset svůj přístup přehodnotit - ne, že by můj zaběhlý způsob nefungoval, ale po prostudování a pochopení těch příkladů můžu dělat stejné věci s menší námahou.

Díky za ten odkaz. Jdu přepisovat aplikace

[Petr Bravenec]

Tak jsem si prostudoval ještě svoje aplikace - přepisování nemá smysl. Zjednoduším tím zápis vlákna za cenu složitějšího zápisu hlavního procesu. V hlavním procesu se mi implementační detaily vlákna nelíbí, takže to budu dělat i nadále "téměř wrong", dědit QThread a start vlákna a související procedury dělat v konstruktoru vlákna.

Dovolil bych si jen jednu poznámku, která v odkazu uvedeném výše není vůbec zmíněná. Uvedené příklady vše řeší přes frontu zpráv, kde v zásadě k problémům nedochází, pokud teda nemám třeba ten nápad posílat z vlákna do vlákna například reference. Občas je potřeba volat z jiného vlákna nějakou metodu přímo, třeba:

worker->stop();

Zde je třeba pamatovat na to, že ač je worker v jiném vlákně s vlastní frontou zpráv, takové přímé volání frontu zpráv obchází a probíhá v hlavním vlákně - zde je nutné používat mutexy, případně v metodě stop() vyvolat signál propojený se slotem, který teprve provede žádanou akci.

Problematika vláken je prostě složitější, než je popsáno v onom odkazu a v článcích typu "wrong" a "not so wrong", a je velmi jednoduché střelit se do nohy, když se s vlákny zachází neopatrně.