habe einen Thread, der ein Event setzen soll, wenn er was gemacht hat und an anderer Stelle soll ein Dialog etwa 1s auf das das Setzen des Events warten und dann weitermachen, oder nach Ablauf der Sekunde eine Meldung machen (falls der Event bis dahin nicht gesetzt wird).

CEvent evtParameter;

Setze evtParameter so:

MyDlg->evtParameter.SetEvent();

und warte an anderer Stelle (nicht im Thread) auf das Event

if (WaitForSingleObject(MyDlg->evtParameter,1000) == WAIT_TIMEOUT) AfxMessageBox("NO PARAMETER AVAILABLE!", MB_OK | MB_ICONSTOP);

Leider passiert aber folgendes:
Der Thread läuft nur bis zu dem Befehl SetEvent() und wartet dann (!?!) und das WaitForSingleObject läuft immer in den Timeout. Nachdem der Timeout eingetreten ist, läuft der Thread ironischerweise weiter...

vielen herzlichen Dank, daß sich Du dich erbarmst und Dich meines Problems annimmst...

so sieht die Methode aus, die auf das vent warten soll:

void CX303ParameterDlg::OnAnfordernMasterAll()
{
  int		i,j,error;

  BOOL				State;
  LWORD				lwError;
  COMSTAT			ComStat;

  CString		cstrTmp;
  BYTE			byteTmp[32];
  unsigned int	crc;

  CSingleLock sLockSerial(&(X303MonitorDlg->csSerial),TRUE);	// SingleLock Objekt konstruieren, da "TRUE" -> Lock() wird aufgefufen!
																// bei Verlassen der Methode durch den Destructor des SingleLock-Objekts sLockSerial
																// von wird automatisch Unlock() aufgerufen!

		#ifdef DEBUG_LOG
   	      fprintf(FP_LOG,"************ OnAnfordernMasterAll **************\n");
		#endif

  evtParameter.ResetEvent();

  crc = 0;
  crc = calc_crc(crc,0x02);
  crc = calc_crc(crc,0x02);
  crc = calc_crc(crc,0x7A);					
  crc = calc_crc(crc,0x03);
  crc = calc_crc(crc,0);
  crc = calc_crc(crc,0);

  byteTmp[0] = 0x02;
  byteTmp[1] = 0x02;
  byteTmp[2] = 0x7A;
  byteTmp[3] = 0x03;
  byteTmp[4] = (crc & 0xFF);				// CRC-Low-Byte übertragen
  byteTmp[5] = (crc >> 8);					// CRC-High-Byte übertragen

  		#ifdef DEBUG_LOG
		  fprintf(FP_LOG,"CRC: %d",crc);
          MEM_DUMP2(byteTmp,"byteTmp: ",16,6);
		  fprintf(FP_LOG,"\n");
		#endif

  error = SeriellSend(hSerialPort,byteTmp,6);

  State = ClearCommError(hSerialPort,&lwError,&ComStat);

		#ifdef DEBUG_LOG
		  //lwError = GetLastError();
		  fprintf(FP_LOG,"ERROR-R:  %04X -> ",lwError);;
		  if (lwError == 0) fprintf(FP_LOG,"OK\n");
		  else if (lwError == CE_BREAK) fprintf(FP_LOG,"CE_BREAK\n");
		  else if (lwError == CE_BREAK) fprintf(FP_LOG,"CE_BREAK\n");
		  else if (lwError == CE_FRAME) fprintf(FP_LOG,"CE_FRAME\n");
		  else if (lwError == CE_IOE) fprintf(FP_LOG,"CE_IOE\n");
		  else if (lwError == CE_MODE) fprintf(FP_LOG,"CE_MODE\n");
		  else if (lwError == CE_OVERRUN) fprintf(FP_LOG,"CE_OVERRUN\n");
		  else if (lwError == CE_RXOVER) fprintf(FP_LOG,"CE_RXOVER\n");
		  else if (lwError == CE_RXPARITY) fprintf(FP_LOG,"CE_RXPARITY\n");
		  else if (lwError == CE_TXFULL) fprintf(FP_LOG,"CE_TXFULL\n");
		#endif

	sLockSerial.Unlock();

				#ifdef DEBUG_LOG
				  fprintf(FP_LOG,"**-P1-**\n");
					if (::WaitForSingleObject(evtParameter.m_hObject,0) == WAIT_OBJECT_0) fprintf(FP_LOG,"EVENT GESETZT!\n");
					else fprintf(FP_LOG,"EVENT NICHT GESETZT!\n");

				  fprintf(FP_LOG,"\n");
				#endif

	// wartet auf deas Eintreffen derParameter TimeOut = 1s
	if (::WaitForSingleObject(evtParameter.m_hObject,0) == WAIT_TIMEOUT) AfxMessageBox("NO PARAMETER AVAILABLE!", MB_OK | MB_ICONSTOP);

    //for (i=0;i<200000000;i++) j = i;
    //while (::WaitForSingleObject(evtParameter.m_hObject,0) == WAIT_TIMEOUT);

				#ifdef DEBUG_LOG
				  fprintf(FP_LOG,"**-P2-**\n");
					if (::WaitForSingleObject(evtParameter.m_hObject,0) == WAIT_OBJECT_0) fprintf(FP_LOG,"EVENT GESETZT!\n");
					else fprintf(FP_LOG,"EVENT NICHT GESETZT!\n");

				  fprintf(FP_LOG,"\n");
				#endif

	// Master-Paramter setzen
	for (i=0;i<PARAMETER_ANZAHL;i++) 
	{
	  cstrTmp.Format("%d",shortParameterMaster[i]);
	  m_Parameter[i].SetWindowTextA(cstrTmp);
	}

}

und hier wird das Event gesetzt:

// Group (byteTmp) = 2 -> Parameter (2 Byte Integer)
			// 0x41 - 0x4C -> Status Master - alle Parameter
		    j = *(byteTmp + 1) & 0xFF;								// Command-Byte sichern

	        cstrTmp.Format("%2d",10);								// Zahl der Parameter
	        Dlg->m_DatenListe.SetItemText(nItem, 2, cstrTmp);

	        cstrTmp.Format("%02X",*(byteTmp + 1));					// Command ausgeben
	        Dlg->m_DatenListe.SetItemText(nItem, 3, cstrTmp);	

			sLockSerial.Lock();
			error = SeriellReceive(hSerialPort,byteTmp,20);			// Parameter holen
			sLockSerial.Unlock();

		    #ifdef DEBUG_LOG
              MEM_DUMP2(byteTmp,"byteTmp -P-: ",16,2);
		      fprintf(FP_LOG,"\n");
		    #endif

			for (i=0;i<(PARAMETER_ANZAHL * 2);i++)
		    {
		      //sLockGUI.Lock();
		      *pbyteInput = *(byteTmp + i);
		      if ((pbyteInput - byteInput) < MAX_INPUT) pbyteInput++;
		      //sLockGUI.Unlock();
			  crc = calc_crc(crc, *(byteTmp + i));					// Parameter High-Byte zur Checksumme hinzufügen
		    }

			cstrTmp.Format("ALLE PARAMETER              - MASTER");
		    Dlg->m_DatenListe.SetItemText(nItem, 6, cstrTmp);

				#ifdef DEBUG_LOG
				  MEM_DUMP2(byteTmp,"byteTmp P-ALL: ",20,20);
				  fprintf(FP_LOG,"\n");
				#endif

			for(i=0;i<PARAMETER_ANZAHL;i++) shortParameterMaster[i] = *(((unsigned short *) byteTmp) + i);

			evtParameter.SetEvent();

				#ifdef DEBUG_LOG
				  fprintf(FP_LOG,"**--**\n");
					if (::WaitForSingleObject(evtParameter.m_hObject,0) == WAIT_OBJECT_0) fprintf(FP_LOG,"EVENT GESETZT!\n");
					else fprintf(FP_LOG,"EVENT NICHT GESETZT!\n");

				  fprintf(FP_LOG,"\n");
				#endif

			// Master-Paramter setzen
			for (i=0;i<PARAMETER_ANZAHL;i++) 
			{
			  cstrTmp.Format("%d",shortParameterMaster[i]);
			  Dlg2->m_Parameter[i].SetWindowTextA(cstrTmp);
			}

			cstrTmp2 = "";
			for(i=0;i<PARAMETER_ANZAHL;i++)
			{
			  cstrTmp.Format("% 5d ",*(((unsigned short *) byteTmp) + i));
			  cstrTmp2 += cstrTmp;
			}
	        Dlg->m_DatenListe.SetItemText(nItem, 4, cstrTmp2);

der untere Teil zum Setzen des Events steck in einem Workerthread, der sonst auch gut funzt Zur Zeit verwende ich einen modeless-Dialog zum Anzeigen und editieren der Paramter - deshalb schreibt der Thread via Dlg2 direkt in den Dialog... Habe ich so gemacht, weil die Warterei nicht tut. Das Event wird aber tatsächlich gesetzt, was ich mit den Kontrollausgaben geprüft habe...

CEvent evtParameter;

Guck mal da:

MSDN schrieb:

CEvent(
BOOL bInitiallyOwn = FALSE,
BOOL bManualReset = FALSE,
LPCTSTR lpszName = NULL,
LPSECURITY_ATTRIBUTES lpsaAttribute = NULL
);

Das bedeutet ein default konstruiertes CEvent ist ein "auto reset" Event. Und das wiederum bedeutet dass das erste WaitForSingleObject den Status auf "non signaled" zurücksetzt.

Vorausgesetzt du hast die Zeile oben nicht falsch abgetippt könnte das das Problem erklären. Auto reset Events sind grundsätzlich kein Problem (sondern oft sehr sehr nützlich), allerdings darf man genau solche Debug-Checks wie du welche in deinem Code hast damit nicht machen.

----

Das ganze sieht für mich aber sowieso nicht ganz sauber aus. Ich behaupte nicht dass es garantiert falsch ist, aber ich würde es niemals so machen.

Erstmal lass mich sagen dass die ganze Kommunikation mit dem Device in eine eigene Klasse wandern sollte. GUI und "Serielles Protokoll ABC für Device XYZ" sind zwei so grundlegend verschiedene Dinge, das sieht ein Blinder dass man das nicht mischen sollte

So. Zurück zu "sieht unsauber aus". Ich würde z.B. nicht aus zwei verschiedenen Threads die Serielle Schnittstelle ansteuern um mit einem Gerät zu kommunizieren. Vor allem nicht so dass Thread A einen Request abschickt und Thread B dann auf die Antwort wartet. Nicht wenn es nicht notwändig ist (und das ist es oft nicht). Wenn du einen 2. Thread hast der die Antwort empfangen soll dann lass den auch den Request abschicken.

Um weiteres zu sagen müsste man wissen um was für eine Art Gerät es sich handelt, also was das kann, welches Protokoll es spricht, und natürlich auch was man mit dem Gerät machen will.

----

Wenn du noch nicht allzuviel Code geschrieben hast mach einfach ein neues Projekt, mach ein schönes Design, und implementiere die nötigen Funktionen dann indem du die entsprechenden Codestücke aus dem alten Projekt dorthin kopierst wo sie hingehören, und entsprechend anpasst.

Wenn das Projekt schon grösser ist ist hier mächtig Refactoring angesagt

hustbaer schrieb:

Das ganze sieht für mich aber sowieso nicht ganz sauber aus.

Aber wie soll ich das sonst machen: Ich habe einen Button im GUI, das einen Befehl an die Schnittstelle schickt und die Antwort soll von einem Thread im Hintergrund erledigt werden, der die Schnittstelle ständig pollt. Das GUI soll halt nicht einfrieren. Auf der anderen Seite sollen die Antwort im GUI dargestellt werden, also muß doch der Thread auf das GUI zugreifen, oder nicht?

Mach es doch so, dass der Thread die Daten in einer Datenstruktur bereitstellt. Das GUI kannst du dann per PostMessage davon unterichten, dass Daten da sind.

Allerdings ist es sowieso recht schwer für mich dir zu erklären wie ich das machen würde. Der Code den du da gepostet hast ist halt einfach ziemlich grauenhaft, und dass du nachfragst wie man es nun besser machen könnte lässt mich einfach vermuten dass du nicht so wahnsinnig viel Erfahrung hast.

Blöderweise ist aber die Aufgabe mit der du da kämpfst auch nicht gerade eine der einfachsten, schon garnicht wenn man dem Programm ein sauberes Design verpassen möchte.

Im Prinzip sollte man auf jeden Fall alles was mit der Kommunikation mit dem Device zu tun hat in eine eigene Klasse kapseln. Doof ist nur die Frage: wie soll das Interface so einer Kasse aussehen. Wenn asynchrone Operationen nötig sind wird das recht schnell recht unübersichtlich für jmd. der sowas noch nie gemacht hat.

Wenn du das ganze halbwegs einfach und übersichtlich halten willst ist das was Burkhi geschrieben hat schonmal keine schlechte Idee. Wenn du nun vom Dialog aus dem Thread irgendetwas mitteilen musst, kannst du auch Window Messages verwenden, oder auch Thread Messages (im Prinzip dasselbe wie eine Window Message, nur mit PostThreadMessage abgeschickt - so bräuchte der "Device polling Thread" kein Fenster).