✔ HANDLE geht verloren

[sTEk]

Ich programmiere über MFC und habe ein dickes Problem:

Ich öffne den COM-Port und bekomme dafür ja ein HANDLE zurück...so weit, so gut. Ich kann auch alles machen, bis zu dem Zeitpunkt, wenn ich einen modalen Dialog aufmache und versuche, mit dem Handle zu arbeiten. :/
Irgendwie läuft der COM-Port im Hintergrund, denn die Nachrichten kann ich abfangen, aber sobald ich eine Aktion auf dem Port ausführen möchte, sagt er mir, dass der HANDLE ungültig ist. (ist 0) *heul*

Der Port wird in meinem MainView gestartet (über eine weitere Klasse) und ich fange im MainView die Nachrichten ab...dann öffne ich den modalen Dialog (das Abfangen der Nachrichten im "Hintergrund" funktioniert noch) und greife auf eine Funktion des MainView zu, welche auf den COM-Port schreibt...und da kommt die Fehlermeldung! (aus der COM-Port-Klasse, da dort mit assert(HANDLE !=0) geprüft wird)

 

[Endurion]

Wenn das Handle vorher da ist, und hinterher 0 ist, dann gibt es nur zwei Möglichkeiten:

A) Das Handle wird irgendwo automatisch zurückgesetzt (Verbindungsabbruch?)

B) du hast da ein zweites Handle, dass mit dem ersten nichts zu tun hat. Wie greifst du denn auf den MainView vom Dialog aus zu? Doch hoffentlich über einen gemerkten Pointer oder Ähnliches?

 

[sTEk]

zu A) Das Handle läuft, denn ich überwache Meldungen vom COM-Port, also so was wie WM_COM_RXCHAR - und die kommen auch an, wenn der modale Dialog offen ist. (Lasse da Funktionen im Main aufrufen, die mir die Infos anzeigen)

zu B)

CKabSOFTView* baba=(CKabSOFTView*) GetParentOwner(); 
 baba->KabtecSenden(sender,m_handle);

...so greife ich auf die Funktion vom Dialog aus zu - klappt auch wunderbar, nur dass die dort drin stehende Funktion fürs Schreiben auf den COM-Port (andere Klasse) den Fehler zurück gibt. Beim Aufruf im Hauptfenster klappt jedoch alles wunderbar.

 

[Endurion]

Hmm, ich frage mich, ob GetParentOwner wirklich den View zurückgibt. Wenn es das nicht tut, macht der Cast zwar ein CKabSOFTView* daraus, aber es ist kein "komplettes" Objekt. Das könnte dann auch das kaputte Handle erklären. Prüf mal, ob der Wert von baba wirklich dem this von deinem CKabSOFTView entspricht (lass dir das this im Constructor ausgeben).

Dank dem allmächtigen C/C++ kann man Objekte brutal auch da hincasten, wo es sie gar nicht gibt. Das läuft dann soweit ganz gut, bis man versucht, eine der Membervariablen anzusprechen (Prüf innerhalb des Aufrufs auch mal, welche Werte einige der anderen Membervariablen haben).

 

[sTEk]

Gaaaaaanz dicken Dank an Dich Endurion!
Hatte doch tatsächlich das falsche Handle zum KabSOFTView. Es gingen zwar alle eigenen Funktionen und Membervariablen aufzurufen, aber wenn ich auf Funktionen einer in der KabSOFTView eingebundenen Klasse zugreifen wollte ging das nicht - warum auch immer... ?)

Auf alle Fälle habe ich mir das Handle vom KabSOFTView in den modalen Dialog übergeben und rufe dann mit diesem die Funktion auf - und alles klappt ganz wunderbar! *freu*

Hier mal die Codeschnipsel, falls jemand mal wieder das Problem hat:
Hier wird der modale Dialog aufgerufen:

//Klasse CTestView
 HANDLE hier=this;
 
 Dlg1.m_handle=hier;
 Dlg1.DoModal();

im modalen Dialog dann an gewünschter Stelle:

CTestView* baba=(CTestView*)m_handle; 
  baba->Senden(sender,0); //Das ist die Funktion in der Klasse CTestView

So kann man getrost auf Funktionen zugreifen, die in einer in CTestView deklarierten Klasse (bspw. CSerialPort) auftreten.