Threads



  • Lass es lieber bei der üblichen Vererbungsbeziehung - CWinApp ist selber von CWinThread abgeleitet und stellt noch einiges an zusätzlicher Funktionalität bereit, die für die zentrale Steuerung nötig ist. In deiner WinApp-Klasse (und ihren Helfern - CMainFrame, CView etc) kannst du dich dann um alle Anzeigen kümmern.

    (btw, SDI ohne Doc/View - wie soll das denn gehen?)



  • CStoll schrieb:

    Lass es lieber bei der üblichen Vererbungsbeziehung - CWinApp ist selber von CWinThread abgeleitet und stellt noch einiges an zusätzlicher Funktionalität bereit, die für die zentrale Steuerung nötig ist. In deiner WinApp-Klasse (und ihren Helfern - CMainFrame, CView etc) kannst du dich dann um alle Anzeigen kümmern.

    das hab ich ja derzeit, nur das hilft mir nichts bezueglich meines freezings

    in meinem programm finden 3 laengere aufgaben statt welche ueber COM statt finden .. sobald diese laufen friert die app ein, darum hab ich ja nach guithread gefragt, die COM anfragen in nem arbeitsthread auszulagern habe ich bisher noch nicht geschafft /=

    CStoll schrieb:

    (btw, SDI ohne Doc/View - wie soll das denn gehen?)

    MFC app erstellen - single document und doc/view architektur ausschalten, dann hat man die app.cpp, frame.cpp und view.cpp
    die view kann man wegkloppen, und in der frame.cpp ein splitter rein wo eine ctopframeview und cbottomframeview benutzt werden
    die frame.cpp kann auf die beiden klassen direkt zugreifen, und die klassen selber schicken immer ne message an den frame {sind bei mit nur 2 von der top und 1 von der button klasse



  • Mr Evil schrieb:

    in meinem programm finden 3 laengere aufgaben statt welche ueber COM statt finden .. sobald diese laufen friert die app ein, darum hab ich ja nach guithread gefragt, die COM anfragen in nem arbeitsthread auszulagern habe ich bisher noch nicht geschafft /=

    Das wäre aber die elegantere Lösung - zeig doch mal, was du versucht hast.
    (Wichtig: Der Worker-Thread darf nicht direkt auf dein Fenster zugreifen - aber er darf Messages an das Hauptprogramm schicken, wenn er etwas dargestellt haben will)



  • sie greifen nicht zu

    das habe ich

    class CMainFrame : public CFrameWnd
    {
    protected:
        LRESULT OnTest(WPARAM wParam, LPARAM lParam);
        CComClass* pCross;
        static UINT thread_entry(LPVOID lpvoid)
        {
            return static_cast<CMainFrame*>(lpvoid)->Test();
        }
        int Test();
    };
    
    LRESULT CMainFrame::OnTest(WPARAM wParam, LPARAM lParam)
    {
        try
        {
            CWinThread *pThread = AfxBeginThread(thread_entry, this);
            ::WaitForSingleObject(pThread, 10000);
            return (pCross) ? TRUE : FALSE;
        }
        catch(...)
        {
            return FALSE;
        }
        return TRUE;
    }
    
    int CMainFrame::Test()
    {
        pCross = CComClass::Connect();
        return 0;
    }
    

    wenn ich statt AfxBeginThread das Connect direkt in der OnTest aufrufe, dann funktioniert es,
    wenn ich in der Test() eine messagebox anzeigen lasse, funktioniert es,
    aber sobald ich dieses versuche, wird das AfxBeginThread direkt uebersprungen, also es sieht aus als wenn es nicht aufgerufen wird



  • Hast du mal versucht, GetLastError() und vergleichbare Fehlerkennungen auszuwerten?

    (btw, wenn du direkt auf deinen Thread wartest, bringt das keinen Vorteil gegenüber der bisherigen Vorgehensweise)



  • GetLastError liefert 0
    mit dem Wait hab ich nur zum test drinnen, ich denk dass ich die status abfrage per timer loesen muss
    sobald ich in den thread auf "pCross" oder dem "CComClass::Connect()" zugreife wirds uebersprungen



  • Ist ja klar das dir das GUI einfriert. Du bleibst ja in der OnTest hängen weil du auf den Thread wartest. Thread starten und vom Thread aus signalisieren wenn er fertig ist könnte hier helfen. Ich kenn mich zwar nicht mit dem ganzen COM-Zeugs aus aber ich muss CStoll Recht geben: SDI ohne Doc/View macht wenig Sinn auch wenn man es da einstellen kann.



  • AndyDD schrieb:

    Ist ja klar das dir das GUI einfriert. Du bleibst ja in der OnTest hängen weil du auf den Thread wartest.

    ne, wenn ich es mit thread mache, friert nichts ein, da das com nichtmal mehr benutzt wird, es wird schlichtweg uebersprungen

    zb

    int CMainFrame::Test()
    {
        AfxMessageBox(_T("Test"));        // funktioniert
        pCross = CComClass::Connect();    // wird nicht aufgerufen
        return 0;                         // funktioniert
    }
    


  • Ich kenne mich auch nicht besonders gut mit COM aus - aber womöglich stellt ja der Com::Connect()-Aufruf das Problem dar. Kannst du den Aufruf mal debuggen?



  • ne, leider nicht, hab ich schon probiert, ich kommt mit dem debugger dort nichteinmal rein /=
    das curiose ist ja auch das ich nichtmal auf pCross zugreifen kann {hab versucht NULL zuzuweisen}
    wegen diese ganzen problemen hatte ich ja versucht die oberflaeche in einen separaten thread laufen zu lassen


  • Mod

    Um einen neuen GUI Thread zu starten erzeugst Du einen eigene Klasse, die Du von CWinThread ableitest. Der verpasst Du DEFINE_/IMPLEMENT_DYNCREATE.

    Dann verwendest Du die Funktion von AfxBeginThread, die den Klassen Namen übernimmt.

    Nun einfach InitInstance überschreiben, Deine Fenster erzeugen und als letztes einfach CWinThread::Run ausführen.

    Thats it...


  • Mod

    CWinThread *pThread = AfxBeginThread(thread_entry, this); 
            ::WaitForSingleObject(pThread, 10000);
    

    Das dieser Code tödlich ist, ist Dir auch klar.

    Ohne weitere Vorkehrung ist das Threadobjekt nämlich zerstört, wenn der Thread beendet wird und WaitForSingleObject retruniert evtl. nie. (Siehe m_bAutoDelete)



  • Martin Richter schrieb:

    Um einen neuen GUI Thread zu starten erzeugst Du einen eigene Klasse, die Du von CWinThread ableitest. Der verpasst Du DEFINE_/IMPLEMENT_DYNCREATE.

    Dann verwendest Du die Funktion von AfxBeginThread, die den Klassen Namen übernimmt.

    Nun einfach InitInstance überschreiben, Deine Fenster erzeugen und als letztes einfach CWinThread::Run ausführen.

    Thats it...

    Klingt einfach, so hatte ich das auch in erinnerung - mein problem ist die umsetzung

    also
    - VS 05 anwerfen
    - neues MFC projekt mit dem namen TestApp
    - SDI
    - fertig

    nun geh ich zu dem einstiegspunkt in der TestApp.cpp und aendere das CWnd nach CWinThread ab und die dazugehoerigen DYNCREATE usw
    InitInstance ist ja schon da, also schmeiss ich da nur ien paar sachen raus, und lassn compiler laufen
    der bemaengelt nichts
    start -> peng, direkt am start, kommt bei InitInstance nichteinmal rein /=


  • Mod

    Wo änderst Du bitte ein CWnd in ein CWinThread?

    Gib mit mal einen Link auf Dein Demo-Projekt...



  • ich glaube ich hab etwas

    in der InitInstance der TestApp

    CWinThread *thread = AfxBeginThread(RUNTIME_CLASS(CMain));
    thread->Run();

    //CMain ist von CWinThread abgeleitet

    in der InitInstance von CWinThread wirt das MainFrame erstellt und angezeigt
    also das TestApp nicht durch den CWinThread ersetzt sondern diese klasse dazwischen geschaltet !!
    compiler rennt und programm laeuft

    werds morgen ma test umsetzen in meiner anderen app
    wuenscht mir glueck #gg



  • ne frage dazu

    was muss ich beachten um die app nun richtig zu beenden?
    In der MainFrame habe ich OnClose ueberladen fuer postwork, was muss ich nun beachten?

    beim test nun hat es sich ergeben dass - wenn ich das programm schliesse, bleibts im hintergrund noch aktiv



  • Hier ist mal die TestApp
    startet normal und ich glaube auch in nem thread, aber wenn ich es beende, bleibt der task noch aktiv .. zu huelf /=
    Klick for download



  • Bei COM bitte auch beachten dass du CoInitialize(Ex) aufrufen musst. Und dass es 2 verschiedene Apartment-Models gibt, nämlich Multithreaded und Singlethreaded. Und dass man Interface-Zeiger aus einem Apartment nicht in einem anderen verwenden kann, sondern diese Marshalen muss.
    Alles sehr unübersichtlich und etwas kompliziert, vor allem wenn es alles neu für einen ist. Leider.

    Viel mehr als "lies dir einiges zum Thema COM und Apartments durch" kann ich aber auch nicht schreiben, auch nur das wichtigste zusammenzufassen würde über einige Seiten gehen (zumindest wenn man es so formulieren will dass es jmd. verstehen kann der es nicht sowieso schon weiss).



  • ok, danke
    nun waere es aber ersteinmal interessant wieso meine applikation nach dem beenden noch weiter laeuft, siehe eine seite zuvor ganz unten

    ich vermute das der winthread in suspend reingeht statt zu beenden, nur AfxEndThread, WM_QUIT, SendExitCode und was es nicht alles gibt an den verschiedenen positionen bringt alles nichts
    das ist der aufbau

    (CMain ist die CWinThread klasse)
    einstieg in der CTestApp::InitInstance -> CMain::InitInstance -> CMainFrame


  • Mod

    Mr Evil schrieb:

    CWinThread *thread = AfxBeginThread(RUNTIME_CLASS(CMain));
    thread->Run();

    Falsch falsch falsch.

    Dadurch startest Du einen Thread, aber fürhrst eine MessagePump im alten Thread aus. Der neue hat dann keine.


Anmelden zum Antworten