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;

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

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

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

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

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)

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

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

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
}

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

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)

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

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

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

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

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

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

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.

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.

Hmm - und wie funktionierts dann richtig, bin nu voellig ratlos, kannst ja die TestApp anschaun, wenn ich das Thread->Run() weg lass, startet gar nichts

Also nochmal
InitInstance überschreiben in Deiner neue Klasse überschreiben. Und dort Dein Fenster erzeugen und am Ende Run/DoModal ausführen und FALSE returnieren.

Aonsonsten InitInstance ausführen. Das eigene Fenster erzeugen und TRUE returnieren. Run wird dann ausgeführt.

Das ist doch nicht anders als in einem normalen MFC Programm.

Dein Thread terminiert durch zerstören des Main-Fensters...