QSerialDevice never comes back if device unavailable

QSerialDevice is working just fine - reads and writes with no problems (thanks for all of your hard work Denis!), unless the h/w or s/w device on the other end of the serial port is unavailable (like the power is off to the device). Then when you try to write a command to it, it goes away and freezes the application. Not sure how to resolve this.

I would like to give the user a QMessageBox with a warning when this happens.

Thanks for any ideas.

If the words "device unavailable" you mean the situation when the remote device is powered off or there was a break of communication (cable break RS-232), there are two options:
1. If the data exchange with the device you are using two wires: Rx and Tx - it is impossible to determine the availability of hardware or unavailability of the unit! For this purpose, use the software definition of the device: the device first sends a query and await a response from the device during a timeout. If no answer for the timeout - the device is not available. :)
2. If the data exchange with the device you are using more than two wires (such as modems) - then we can determine the availability / unavailability of device (see the description of the standard and goal lines of port RTS, CTS.RI, etc.).
For this case, sufficient to include hardware control "Hardware flow control" - and then the data exchange will occur on the standard. (if I'm not mistaken)

Quote:

---

hen when you try to write a command to it, it goes away and freezes the application.

---

show the source code. likely you do something wrong doing. :)

Thanks for your response.
No doubt it is something I am doing wrong.
Yes, the device is software, so no flow control.
Here is the code and the debug output:

Code:

---

PreferencesDialog::PreferencesDialog(QWidget *parent) :
    QDialog(parent),
    m_ui(new Ui::PreferencesDialog)
{
    m_ui->setupUi(this);
 
    //01202010 - Set up CAT preference values
    AbstractSerial *MyDevice = new AbstractSerial();
    // Getting Available Ports
   QStringList list = MyDevice->serialDevicesAvailable();
   list.sort();
   int len = list.size();
 
   for (int i = 0; i < len; i ++) {
       m_ui->cbPort->addItem(list[i]);
       qDebug() << "Port is " << list[i]; // see debug output below
   }
   MyDevice->close();
   delete MyDevice;
 
// debug output
Port is  "COM1"
Port is  "COM2"
Port is  "COM3"
Windows: NativeSerialEnginePrivate::nativeClose
 -> hd == INVALID_HANDLE_VALUE. Error!
//
 
 
 // Get tx vfo
   cmd = "FT;";
   len = 8;
   ba = cmd.toAscii();
   QByteArray ra = readWrite(port, len, ba);
///
 
 
QByteArray SerialComm::readWrite(QString port, int len, QByteArray ba) {
    AbstractSerial *MyDevice = new AbstractSerial();
    MyDevice->setDeviceName(port);
    if (MyDevice->open(QIODevice::ReadWrite | QIODevice::Unbuffered)) {
        qDebug() << "serial device status is " << MyDevice->deviceName();
 
        qDebug() << "Writing the command";
        MyDevice->write(ba); // see debug output below
        qDebug() << "Command written";
 
        //printDataToHex(ba);
        ba.clear();
    }
 
// debug output
Windows: NativeSerialEnginePrivate::nativeOpen
 -> Trying to open device:  "COM3"
 
Windows: NativeSerialEnginePrivate::nativeOpen
 -> Opened device:  "COM3"  succesfully. Ok!
 
serial device status is  "COM3"
Writing the command
// no response now

---

Doesn't make any difference if I try to timeout the write(ba) command - it just never returns.

Hmm .. All my works. I did rewrote the program from the /examples for reading and writing command "FT;" (see the archive as an attachment).
I tried to write the command "FT;" simply in the serial port PC, which was not connected to anything. I have a "freeze" was not! Maybe you have a "curve" port driver or faulty port?

Thanks for your help Kuzulis. My application is trying to reach a software serial port through a virutal port programmed pair that are established with the program com0com.
Perhaps that is where the problem lies. I will try a different program for making the virtual pair and see if that solves the problem.

OK, I have switched from com0com to VSP Manager and the problem is cured.