Hab jetzt folgendes Problem im weiteren Verlauf. Das mit dem Multithreading hat sich nun dahingehend geklärt das ein Update der RTX erforderlich war um dies zu ermöglichen. Also alles gut.
Nun Starte ich einen Dialog, welcher einen Child-Dialog startet. In dem Child-Dialog starte ich einen Workerthread (obiger Code) in welchem ich allerdings auf Methoden des Parent-Dialogs zugreifen möchte.
C/C++ Code:
ParentDlg* parDlg = (ParentDlg*)GetParent();
C/C++ Code:
ParentDlg* parDlg = (ParentDlg*)GetParent();
C/C++ Code:
ParentDlg* parDlg = (ParentDlg*)GetParent();
funktioniert zwar soweit, jedoch benötige ich den vorher in den Membervariablen enthaltenen Inhalt...
So wie ich das verstehe, erstelle ich eine neue Instanz des Parent-Dialogs, der keinen Bezug mehr auf den "original"-Dialog hat, und alle variablen "Quark" enthalten...
Hab dazu folgendes entdeckt, der auch das gleiche Problen hatte...allerdings Check ich es nicht ganz, wie hier das Problem gelöst werden kann.
Und warum übergibst Du nicht einfach einen Zeiger auf das Parent?
Sobald Du irgend etwas machst, dass ein Window Handle in dem anderen Thread benutzt aus Deinem CDialog fliegt Dir die Funktion um die Ohren. Window Handles und Windows Objekte sind threadlokal.
Warum baust Du keine neutrale Struktur mit den Daten, die sowohl der Thread als auch der Dialog benutzt?
Und warum übergibst Du nicht einfach einen Zeiger auf das Parent?
Wie sähe das aus? Also ich rufe in dem Workerthread eine Memberfunktion des Parent auf. In dieser werden die Membervariablen selbiger verwendet, dort benötige ich aber den, vorher beim start des Programms, geladenen Inhalt.
Zitat:
Warum baust Du keine neutrale Struktur mit den Daten, die sowohl der Thread als auch der Dialog benutzt?
Mangelnde Erfahrung? Keine Ahnung wie sowas aussehen muss...bin noch relativ unerfahren. Wäre das dann so eine Art Globale Variablendeklaration??
Ok, Danke erstmal...aber weiter bringt mich das auch nicht. Vorteile Gegenüber der Vorhergehenden Variante ergeben sich nicht, denn das was ich brauche funktionier immer noch nicht.
Also, ich zeig erstmal was ich jetzt Testweise gemacht habe.
Ein Dialog erstellt namens CTreadTestDlg.
C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12
1 2 3 4 5 6 7 8 9 10 11 12
void CTreadTestDlg::TestFunktion()
{
int Test = m_iAdrBits;
m_iAdrBits++;
}
void CTreadTestDlg::OnButtonstartdlg()
{
// TODO: Add your control notification handler code here
TestClassxD Testdlg;
Testdlg.DoModal();
}
C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12
void CTreadTestDlg::TestFunktion()
{
int Test = m_iAdrBits;
m_iAdrBits++;
}
void CTreadTestDlg::OnButtonstartdlg()
{
// TODO: Add your control notification handler code here
TestClassxD Testdlg;
Testdlg.DoModal();
}
C/C++ Code:
1 2 3 4 5 6 7 8 9 10 11 12
void CTreadTestDlg::TestFunktion()
{
int Test = m_iAdrBits;
m_iAdrBits++;
}
void CTreadTestDlg::OnButtonstartdlg()
{
// TODO: Add your control notification handler code here
TestClassxD Testdlg;
Testdlg.DoModal();
}
Diese Klasse beinhaltet die Memberfunktion Testfunktion(), in welcher auf die Membervariable m_iAdrBits zugegriffen wird.
Mit Klick auf den Button StartDlg wird ein ChildDialog erstellt, in welchem folgendes passiert:
.h file:
C/C++ Code:
1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
static UINT StartThread (LPVOID param); //controlling function header
typedef struct THREADSTRUCT //structure for passing to the controlling function
{
TestClassxD* _this; //this Objekt auf die Child Klasse
CTreadTestDlg* ParentThread; //Objekt des ersten Dialogs
} THREADSTRUCT;
C/C++ Code:
1 2 3 4 5 6 7 8
static UINT StartThread (LPVOID param); //controlling function header
typedef struct THREADSTRUCT //structure for passing to the controlling function
{
TestClassxD* _this; //this Objekt auf die Child Klasse
CTreadTestDlg* ParentThread; //Objekt des ersten Dialogs
} THREADSTRUCT;
C/C++ Code:
1 2 3 4 5 6 7 8
static UINT StartThread (LPVOID param); //controlling function header
typedef struct THREADSTRUCT //structure for passing to the controlling function
{
TestClassxD* _this; //this Objekt auf die Child Klasse
CTreadTestDlg* ParentThread; //Objekt des ersten Dialogs
//you can also call AfxEndThread() here return 1;
}
Und natürlich ist der Fehler immernoch vorhanden, dass wenn ich die Testfunktion des ersten Dialogs aufrufe, ein Access Violation Fehler kommt, weil er den Inhalt von m_iAdrBits nicht kennt...obwohl m_iAdrBits im OnInitDialog() des ersten Dialogs initialisiert und einen Wert erhalten hat.
Ist das was ich will überhaupt möglich? Oder versteht nur niemand was ich möchte?
PS: Das ist jetzt nur ein kleines Beispielprogramm, was ich in meine komplexere Anwendung integrieren muss/möchte...
PS2@Mods: Vielleicht wär es möglich den Titel zu ändern? Ich möchte nur kein neues Thema eröffnen, da es ja alles zusammen hängt...
Titelvorschlag: "aus Workerthread auf Membervariablen eines anderen Dialogs zugreifen" ...wenn das sachlich richtig ist
Zuletzt bearbeitet von KPY3EP am 12:29:37 02.02.2012, insgesamt 1-mal bearbeitet
Du initialisierst in deinem Beispiel THREADSTRUCT::ParentThread nirgends, greifst aber in der Thread-Funktion darauf zu (ts->ParentThread->...).
Ich würde sagen poste mal 1:1 Code aus einem "funktionierenden" Beispiel, mit dem du das Problem nachstellen kannst.
Code den man schnell für's Posten im Forum zurechtschnippelt oder gar "nachtippt" (ohne ihn ausprobiert zu haben) ist in solchen Fällen selten hilfreich.
Und natürlich darfst du nur aus dem Thread auf ein Fenster bzw. einen Dialog zugreifen, der dieses Fenster/diesen Dialog auch erzeugt hat.
D.h. du darfst aus dem Thread nicht auf ts->_this->m_progressBar zugreifen.
Was OK wäre, wäre mit die entsprechende Message mit PostMessage() abzusetzen.
Hmm...danke, aber irgendwie kritisierst du immer das, was funktioniert
Zitat:
D.h. du darfst aus dem Thread nicht auf ts->_this->m_progressBar zugreifen
Warum?! Es funktioniert einwandfrei!
Zitat:
Du initialisierst in deinem Beispiel THREADSTRUCT::ParentThread nirgends, greifst aber in der Thread-Funktion darauf zu (ts->ParentThread->...).
C/C++ Code:
typedef struct THREADSTRUCT //structure for passing to the controlling function
{
TestClassxD* _this; //this Objekt auf die Child Klasse
CTreadTestDlg* ParentThread; //Objekt des ersten Dialogs
} THREADSTRUCT
C/C++ Code:
typedef struct THREADSTRUCT //structure for passing to the controlling function
{
TestClassxD* _this; //this Objekt auf die Child Klasse
CTreadTestDlg* ParentThread; //Objekt des ersten Dialogs
} THREADSTRUCT
C/C++ Code:
typedef struct THREADSTRUCT //structure for passing to the controlling function
{
TestClassxD* _this; //this Objekt auf die Child Klasse
CTreadTestDlg* ParentThread; //Objekt des ersten Dialogs
} THREADSTRUCT
soviel dazu...
Zitat:
Und natürlich darfst du nur aus dem Thread auf ein Fenster bzw. einen Dialog zugreifen, der dieses Fenster/diesen Dialog auch erzeugt hat.
OK! Zumindest hast du das Problem vor dem ich stehe erkannt. Ich versuche ja auch nicht auf Fenster/Controls/Dialog zuzugreifen, sondern auf eine Membervariable der Dialogklasse.
Ich möchte eigentlich nur wissen, ob das wirklich so ein Ding der unmöglichkeit ist. Der Luxus einen weiteren Dialog zu öffnen in welchem man einen Langzeittest starten kann ist einfang sehr Angenehm. Wenn mir aber keine Lösung einfällt/präsentiert wird, werde ich wohl die wenigen Controls aus dem Child-Dialog in den "großen" Parent Dialog implementieren, und diese per Menü einfach Disablen/Enablen...
Nicht Schön, aber wird sich im zuge von Multithreading wohl nicht ändern lassen oder?
Was mich aber immernoch Interessiert, ist Martin Richters vorschlag zur neutralen Struktur
wtf is das? Wie kann ich mir so etwas vorstellen? Kein Plan wie man so etwas angeht.
Hmm...danke, aber irgendwie kritisierst du immer das, was funktioniert
Blubb
Zitat:
Zitat:
D.h. du darfst aus dem Thread nicht auf ts->_this->m_progressBar zugreifen
Warum?! Es funktioniert einwandfrei!
Weil m_progressBar ein CONTROL aka. FENSTER ist. Das darfst du nur aus dem Thread verwenden der es erzeugt hat. OK, unter bestimmten Voraussetzungen funktioniert das auch "gut" über Thread-Grenzen hinweg, man kann sich aber ganz leicht damit rückwärts durchs Knie schiessen.
Zitat:
Zitat:
Du initialisierst in deinem Beispiel THREADSTRUCT::ParentThread nirgends, greifst aber in der Thread-Funktion darauf zu (ts->ParentThread->...).
C/C++ Code:
typedef struct THREADSTRUCT //structure for passing to the controlling function
{
TestClassxD* _this; //this Objekt auf die Child Klasse
CTreadTestDlg* ParentThread; //Objekt des ersten Dialogs
} THREADSTRUCT
C/C++ Code:
typedef struct THREADSTRUCT //structure for passing to the controlling function
{
TestClassxD* _this; //this Objekt auf die Child Klasse
CTreadTestDlg* ParentThread; //Objekt des ersten Dialogs
} THREADSTRUCT
C/C++ Code:
typedef struct THREADSTRUCT //structure for passing to the controlling function
{
TestClassxD* _this; //this Objekt auf die Child Klasse
CTreadTestDlg* ParentThread; //Objekt des ersten Dialogs
} THREADSTRUCT
soviel dazu...
Ist dir die Bedeutung des Wortes "initialisieren" bekannt?
Ja? Glaub ich nicht
C/C++ Code:
1 2 3 4 5 6 7 8 9
1 2 3 4 5 6 7 8 9
void TestClassxD::OnButtonstart()
{
cancelflag = 0;
UpdateData(TRUE);
THREADSTRUCT *_param = new THREADSTRUCT;
_param->_this = this;
// HIER FEHLT EIN _param->ParentThread = irgendwas;
AfxBeginThread (StartThread, _param);
}
C/C++ Code:
1 2 3 4 5 6 7 8 9
void TestClassxD::OnButtonstart()
{
cancelflag = 0;
UpdateData(TRUE);
THREADSTRUCT *_param = new THREADSTRUCT;
_param->_this = this;
// HIER FEHLT EIN _param->ParentThread = irgendwas;
AfxBeginThread (StartThread, _param);
}
C/C++ Code:
1 2 3 4 5 6 7 8 9
void TestClassxD::OnButtonstart()
{
cancelflag = 0;
UpdateData(TRUE);
THREADSTRUCT *_param = new THREADSTRUCT;
_param->_this = this;
// HIER FEHLT EIN _param->ParentThread = irgendwas;
AfxBeginThread (StartThread, _param);
}
Ich glaub du verstehst imemr noch nicht, was ich will...lies dir bitte nochmal meinen Letzten Post unterster Absatz durch.
Zitat:
Weil m_progressBar ein CONTROL aka. FENSTER ist. Das darfst du nur aus dem Thread verwenden der es erzeugt hat. OK, unter bestimmten Voraussetzungen funktioniert das auch "gut" über Thread-Grenzen hinweg, man kann sich aber ganz leicht damit rückwärts durchs Knie schiessen.
Was ne Begründung...
Und warum machen das alle so? Selbst in dem Beispiel welches hier verlinkt wurde wird es so gemacht.
Zitat:
OK! Zumindest hast du das Problem vor dem ich stehe erkannt.
Diese Aussage nehme ich zurück. Ich versuch nochmals zu erklären worum es geht.
Da wird die Membervariable "ParentThread" bloss leider nie geschrieben. D.h. da steht ne Hausnummer drin.
D.h. du greifst nicht auf den "Dialog 1" zu, sondern einfach irgendwo in den Speicher. Und deswegen schnalzt es dort.
Wenn du nicht unglaublich schwer von Begriff bist, müsstest du das eigentlich verstehen.
KPY3EP schrieb:
Ich glaub du verstehst imemr noch nicht, was ich will...lies dir bitte nochmal meinen Letzten Post unterster Absatz durch.
Und ich glaube du hast einfach keine Ahnung von Programmieren.
Zitat:
Zitat:
Weil m_progressBar ein CONTROL aka. FENSTER ist. Das darfst du nur aus dem Thread verwenden der es erzeugt hat. OK, unter bestimmten Voraussetzungen funktioniert das auch "gut" über Thread-Grenzen hinweg, man kann sich aber ganz leicht damit rückwärts durchs Knie schiessen.
Was ne Begründung...
Und warum machen das alle so? Selbst in dem Beispiel welches hier verlinkt wurde wird es so gemacht.
Was kann ich dafür dass Heerscharen von Programmierern keinen Tau von Multithreading haben?
Das m_progressBar.SetPos() ist für sich genommen noch kein Problem.
Problematisch wird es meistens dann, wenn die Leute versuchen den Thread im OnOK/OnClose des "parent" Dialogs zu beenden.
Zitat:
Ich bin zwar sowieso schon damit fertig, und hab es anders gelöst, jedoch interessiert mich ob bzw. was hier die schwierigkeit darstellt...
Dann solltest du vielleicht lesen was ich dir schreiben, anstatt immer nur zu behaupten dass ich dein Problem nicht verstanden habe.
So ein Dialog der nen Worker-Thread rausstartet ist genau überhaupt kein Problem, das hat man in ein paar Minuten runterprogrammiert.
Nächstes Thema anzeigen Vorheriges Thema anzeigen
Sie können Beiträge in dieses Forum schreiben. Sie können auf Beiträge in diesem Forum antworten. Sie können Ihre Beiträge in diesem Forum nicht bearbeiten. Sie können Ihre Beiträge in diesem Forum nicht löschen. Sie können an Umfragen in diesem Forum nicht mitmachen.
c++.de ist Teilnehmer des Partnerprogramms von Amazon Europe S.à.r.l. und Partner des Werbeprogramms, das zur Bereitstellung eines Mediums
für Websites konzipiert wurde, mittels dessen durch die Platzierung von Werbeanzeigen und Links zu amazon.de
Werbekostenerstattung verdient werden kann.
Die Vervielfältigung der auf den Seiten www.c-plusplus.de, www.c-plusplus.info, www.c-sar.de, www.c-plusplus.net und www.baeckmann.de
enthaltenen Informationen ohne eine schriftliche Genehmigung des Seitenbetreibers ist untersagt
(vgl. §4 Urheberrechtsgesetz). Die Nutzung und Änderung der vorgestellten Strukturen und Verfahren in
privaten und kommerziellen Softwareanwendungen ist ausdrücklich erlaubt, soweit keine Rechte Dritter verletzt werden.
Der Seitenbetreiber übernimmt keine Gewähr für die Funktion einzelner Beiträge oder Programmfragmente, insbesondere
übernimmt er keine Haftung für eventuelle aus dem Gebrauch entstehenden Folgeschäden.
Twitter
Facebook
