[Qt 3]statuslineedit doet het te laat

[elgringo]

Ik heb een lineedit waarin ik de status wat een programmam zet. Dit programma is een stukje software wat een foto neemt van een SBIG st-402 camera en dan deze toont.

Als ik begin met het maken van de foto, doe ik:

C++:

statusLine->setText("Grabbing...");

dan wordt de cursor stil gezet en wordt de i/o intensieve actie gedaan:

C++:

QApplication::setOverrideCursor( waitCursor );
    int err;
    
    
    pSbigImg = new CSBIGImg();
    
    pSbigCam->SetExposureTime(dShutter);            
    
    SBIG_DARK_FRAME df=SBDF_DARK_ALSO;  //SBDF_LIGHT_ONLY; SBDF_DARK_ONLY; SBDF_DARK_ALSO
    if (iFrame==0) df=SBDF_LIGHT_ONLY;
    else if (iFrame==1) df=SBDF_DARK_ONLY;
    else if (iFrame==2) df=SBDF_DARK_ALSO;
    
    // reso 2=L, 1=M, 0=H
    pSbigCam->SetReadoutMode(iQuality);
 
    //ccd 0=imaging, 1=tracking
    pSbigCam->SetActiveCCD((CCD_REQUEST)0);
 
    if ( (err=pSbigCam->GrabImage(pSbigImg, df)) != CE_NO_ERROR ) {
    QApplication::restoreOverrideCursor();
    QMessageBox::information((QWidget*)0, "Easy Count Project", "Grab error."); 
    statusLine->setText("Grab error");
    return;
    }
 
    makeImage();
    
    statusLine->setText("Grab complete, ready...");
    QApplication::restoreOverrideCursor();

en de functie makeimage:

C++:

void MainForm::makeImage()
{
    unsigned char *pDest;
    unsigned short *pVid;
    long back, range, vid;
    
    image.reset();
    image.create(pSbigImg->GetWidth(), pSbigImg->GetHeight(),8);
    image.setNumColors(256);
    
    for(int i=0; i<256; i++) image.setColor(bInvertedVideo ? 255 - i : i, qRgb(i,i,i)); // palette maken
    
    pDest=image.bits();
    back=pSbigImg->GetBackground();
    range=pSbigImg->GetRange();
    pVid=pSbigImg->GetImagePointer();
    
    if (range < iMinRange ) range = iMinRange;
    for (int i=0;i<pSbigImg->GetHeight();i++) {
    for (int j=0; j<pSbigImg->GetWidth();j++) {
        vid=*pVid++;
        vid-=back;
        if (vid<0) vid=0;
        else if (vid>=range) vid=255;
        else vid=(vid*255)/range;
        pDest[j]=vid;
    }
    pDest+=image.bytesPerLine();
    }
    
    pixmap.convertFromImage(image,0);
    Picture->setPixmap(pixmap);
    
}

het vreemde is dat de text grabbing nooit komt, ik zie wel dat de cam de foto maakt (aan de hand van de status ledjes), ik zie ook dat als de foto klaar is de text "Grab complete, ready..." komt te staan en als het mis gaat "Grab error", maar nooit de text grabbing...

Hoe kan dit?
Ik maak gebruik van debian met kernel 2.6.12.4.

[ Voor 26% gewijzigd door elgringo op 19-12-2005 09:59 ]

[mOrPhie]

Omdat het om een IO-intensieve actie gaat, denk ik dat de thread waarin het draait gewoon vol komt te staan en geen tijd meer ziet om de label te veranderen. Dit is slechts een aanname, omdat ik niet weet hoeveel CPU hier mee gemoeid gaat. Wellicht dat je het grabben beter in een thread kan onderbrengen. Hiervoor bestaat "QThread" en is vrij gemakkelijk te implementeren. Je voorkomt hiermee dat alles binnen je thread (dus ook je window + childwidgets) blokkeert.

[SlinkingAnt]

Ik denk dat het probleem erin zit dat de guiThread niet meteen ge-update wordt. Een tijdje geleden heb eenzelfde probleem gehad, en onder andere dit topic gevonden. In de laatste reactie staat de oplossing van de TS, welke gebruik maakt van deze functie

[elgringo]

mOrPhie schreef op maandag 19 december 2005 @ 10:15:
Omdat het om een IO-intensieve actie gaat, denk ik dat de thread waarin het draait gewoon vol komt te staan en geen tijd meer ziet om de label te veranderen. Dit is slechts een aanname, omdat ik niet weet hoeveel CPU hier mee gemoeid gaat. Wellicht dat je het grabben beter in een thread kan onderbrengen. Hiervoor bestaat "QThread" en is vrij gemakkelijk te implementeren. Je voorkomt hiermee dat alles binnen je thread (dus ook je window + childwidgets) blokkeert.

Het blokkeren is niet erg, eigenlijk gewenst zelfs.

Ik vind het alleen vreemd dat ik hem al aangeroepen heb voordat de io actie begint.
Dat blokkeren mag wel, anders gaat de gebruiker meerdere keren grabben oid, of de instelling van de cam veranderen tijdens de grab en dat mag niet...

De vraag is nu. Hoe zorg ik dat hij getoond wordt en dan gaat io'en en niet die setext is de wacht zet oid

[elgringo]

SlinkingAnt schreef op maandag 19 december 2005 @ 10:21:
Ik denk dat het probleem erin zit dat de guiThread niet meteen ge-update wordt. Een tijdje geleden heb eenzelfde probleem gehad, en onder andere dit topic gevonden. In de laatste reactie staat de oplossing van de TS, welke gebruik maakt van deze functie

dus dan wordt het, als ik de text er in gezet heb dus functie wakeupguithread aanroepen en dan de io actie?

edit:
ik heb er avn gemaakt:

C++:

    statusLine->setText("Grabbing...");
    QApplication::wakeUpGuiThread ();
    QApplication::setOverrideCursor( waitCursor );

en de compiler:

In file included from .ui/mainform.cpp:33:
mainform.ui.h: In member function `virtual void
MainForm::pushButtonImage_clicked()':
mainform.ui.h:160: error: cannot call member function `void
QApplication::wakeUpGuiThread()' without object
make: *** [.obj/mainform.o] Error 1

[ Voor 29% gewijzigd door elgringo op 19-12-2005 10:34 ]

[bigbeng]

Zo te zien probeer je wakeUpGuiThread als class method aan te roepen. De foutmelding geeft aan dat dit niet kan, maar dat je een geinstantieerd object moet hebben waarmee je wakeUpGuiThread() aanroept. Hoe je dit doet kan ik je helaas bij gebrek aan c++ kennis niet vertellen.

[mOrPhie]

elgringo schreef op maandag 19 december 2005 @ 10:28:
[...]


Het blokkeren is niet erg, eigenlijk gewenst zelfs.

Ik vind het alleen vreemd dat ik hem al aangeroepen heb voordat de io actie begint.
Dat blokkeren mag wel, anders gaat de gebruiker meerdere keren grabben oid, of de instelling van de cam veranderen tijdens de grab en dat mag niet...

Wellicht een meta-discussie dit, maar als je op die manier wil afdwingen dat er meerdere keren geklikt wordt, dan is dat de verkeerde manier, imho. De kans dat iemand alsnog de knop ingedrukt krijgt (met een PC met meer ram en een snellere processor) is aanwezig. Je kunt dan beter de knop tijdelijk disable-en tot het grabben klaar is. Dat is een nettere en zekere manier.

Wat waarschijnlijk evenals het setten van de label geblokkeerd zal worden verder hoor, dat is een ander probleem.

[elgringo]

mOrPhie schreef op maandag 19 december 2005 @ 11:41:
[...]


Wellicht een meta-discussie dit, maar als je op die manier wil afdwingen dat er meerdere keren geklikt wordt, dan is dat de verkeerde manier, imho. De kans dat iemand alsnog de knop ingedrukt krijgt (met een PC met meer ram en een snellere processor) is aanwezig. Je kunt dan beter de knop tijdelijk disable-en tot het grabben klaar is. Dat is een nettere en zekere manier.

Wat waarschijnlijk evenals het setten van de label geblokkeerd zal worden verder hoor, dat is een ander probleem.

dat het geen nette manier is weet ik, dat was ook niet de vraag en een oplossing ben ik mee bezig.

maar dat verklaart nog niet waarom mijn lineedit niet gewijzigd wordt

[elgringo]

Schop? iemand moet dit toch weten?

Ik heb hetzelfde effect ook als ik system(....) doe met een cpu intensieve actie.

[dingstje]

Zoals al aangegeven: breng die intensieve acties onder in een eigen worker thread. Op die manier blokkeert je GUI-thread niet.

[MSalters]

Repaints worden vziw niet meteen doorgevoerd, maar bij de eerstvolgende WM_PAINT of idle time.(of het X equivalent). Je moet dus waarschijnlijk een repaint forceren voordat je main thead blokkeert, (of je main thread niet meer blokkeren, dat is het meest nette)

[elgringo]

dingstje schreef op dinsdag 03 januari 2006 @ 18:38:
Zoals al aangegeven: breng die intensieve acties onder in een eigen worker thread. Op die manier blokkeert je GUI-thread niet.

Dat is een goede optie. Maar kan ik dus eerst een repaint doen en dan hem verder gaten gaan.
Dus eerst text vullen en dan door.

[elgringo]

MSalters schreef op dinsdag 03 januari 2006 @ 21:59:
Repaints worden vziw niet meteen doorgevoerd, maar bij de eerstvolgende WM_PAINT of idle time.(of het X equivalent). Je moet dus waarschijnlijk een repaint forceren voordat je main thead blokkeert, (of je main thread niet meer blokkeren, dat is het meest nette)

repaint werkt ook niet.....

[Remenic]

http://doc.trolltech.com/3.3/qapplication.html#processEvents