4. Threads

Threads

  • E

    Heiho,

    Ueber die suche hier hab ich schon gesehen das es bereits ein paar beitraege gibt welche MFC + thread beinhalten, aber auch nach vielen lesen und probieren hab ich es bisher nicht hinbekommen

    ich habe
    eine applikation:
    mainframe, diese hat ein splitter mit zwei formview klassen
    wie bekomm ich das in einem gui thread,
    ich weiss das ich CWinThread ableiten soll, aber wie hab ich bisher nicht rausgefunden
    kann mir jemand helfen oder gar eine kleine beispiel applikation zukommen lassen mit einen MainFrame und einen splitter mit den FormViews?
    Waere sehr nett {o;

    0

  • Üblich ist es den main Thread als GUI Thread zu verwenden, d.h. du musst *garnix* dazu machen.
    Das einzige was du in Threads auslagerst sind Aufgaben die länger dauern können, das werden dann Worker-Threads.
    Zumindest hab ich es bis jetzt immer so gemacht, funktioniert eigentlich toll.

    GUI mit mehreren Threads ist problematisch, würde ich nicht machen (z.B. Parent-Child Relation zwischen Fenstern verschiedener Threads kann zu seltsamen Fehlern führen).

    0
  • E

    hustbaer schrieb:

    Üblich ist es den main Thread als GUI Thread zu verwenden

    Hab ich mir auch gedacht, aber sobald ich es versuch schmierts direkt beim start ab
    ich habe eine MFC app erstellt mit SDI ohne Doc/View, ich habe:

    class CTestApp : public CWinApp

    diese ruft auf: (bei InitInstance)

    CMainFrame* pFrame = new CMainFrame;
if (!pFrame)
	return FALSE;
m_pMainWnd = pFrame;
pFrame->LoadFrame(IDR_MAINFRAME, WS_OVERLAPPEDWINDOW|FWS_ADDTOTITLE, NULL, NULL);
pFrame->ShowWindow(SW_SHOW);
pFrame->UpdateWindow();
return TRUE;

    dann dacht ich, leiteste von CWinThread statt CWinApp ab, nur dann kommt er nicht einmal zu den InitInstance.
    Declare_Dyncreate und Implement_Dyncreate sind gesetzt /=

    0
  • C

    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?)

    0
  • E

    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

    0
  • C

    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)

    0
  • E

    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

    0
  • C

    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)

    0
  • E

    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

    0
  • A

    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.

    0
  • E

    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
}
    0
  • C

    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?

    0
  • E

    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

    0
  • 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...

    0
  • 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)

    0
  • E

    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 /=

    0
  • Mod

    Wo änderst Du bitte ein CWnd in ein CWinThread?

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

    0
  • E

    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

    0
  • E

    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

    0
  • E

    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

    0
Anmelden zum Antworten