Muchos buenos programadores (incluidos muchos buenos miembros de Stackoverflow) están en contra de usarApplication.DoEvents() Cualesquiera que sean las circunstancias. En realidad, incluso es compatible con muchos artículos en la red, comoéste, este famoso debate sobre SO, ...

Sin embargo, estoy atrapado en un caso, donde (creo)DoEvents() Es la salida única (falta de experiencia). Eso es suficiente como introducción, veamos algo de codificación.

Tengo un componente 'serialPort' para conectarme con un controlador a través de la comunicación en serie, enviar un comando y esperar su respuesta, eso es todo.

string response = "";
bool respFlag;

private string sendCommand(string command)
{
  respFlag = false;  //initialize respFlag

  serialPort1.Write(command);  // send the command

  Stopwatch timer = Stopwatch.StartNew(); // start a timer
  while(true)
  {
    // break from the loop if receive a response
    if(respFlag) break;  

    // timeOut error if no response for more than 500msec
    if(timer.ElapsedMilliseconds >= 500) break;

    // here comes the UGLY part
    Application.DoEvents(); 
  }

   return response;
}

en el método DataReceived de mi serialPort, leo la respuesta existente y rompo el ciclo

private void serialPort1_DataReceived(object sender, SerialDataReceivedEventArgs e)
{
  response = serialPort1.ReadExisting();

  // set the flag to true to exit the infinite loop in sendCommand
  respFlag = true; 
}

No es exactamente así, pero este es un código de muestra que muestra cómo recibí el sned a través de la comunicación en serie, ¿podría mostrarme amablemente dónde me estoy obligando a enfrentar esta trampa?