Trouble with live communication with QProcess and VS C++ - c++

I'm trying to establish a live communication between a QT program and a VS C++ program. However, I can read anything unless I close the writechannel in which I can't write anything anymore. Furthermore, the code I have now reads a continuous stream of output when I write one line to the VS C++ program when it should be waiting for the next input. Is there a way to establish synchronous communication with the two? What is wrong with my current program?
I've read documentation and can't seem to get a clear answer.
My Qt code:
MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::MainWindow)
{
ui->setupUi(this);
process = new QProcess(this);
connect(process, SIGNAL(readyReadStandardOutput()), this, SLOT(readOutput()));
//connect(process, SIGNAL(readyReadStandardError()),this,SLOT(readOutput()));
process->setArguments(args);
process->setProgram("C:\\Users\\chten\\OneDrive\\Desktop\\QProcess\\test\\Debug\\test.exe");
process->start();
process->waitForStarted();
}
MainWindow::~MainWindow()
{
delete ui;
}
void MainWindow::readOutput() {
ui->input->append(process->readAllStandardOutput());
}
void MainWindow::on_pushButton_2_pressed()
{
process->write("left");
process->waitForBytesWritten();
process->closeWriteChannel();
}
My C++ code:
cout << "waiting for response..." << endl;
string input_line;
//getline(cin, input_line);
//cout << input_line << endl;
while (true) {
getline(cin, input_line);
cout << input_line << endl;
for(int i = 0; i<9999999; i++){}
}
return 0;

I think the problem is that you never write a line to the child process, you just have...
process->write("left");
No newline. In the meantime the child is executing...
getline(cin, input_line);
waiting for the newline delimiter.
The reason closing the write channel appears to work is that it will cause the getline call in the child to receive an end-of-file condition and return. However, it will also set the eofbit in the input stream's state causing further calls to getline to return immediately: hence the "continuous stream of output" you refer to.
Try changing the implementation of MainWindow::on_pushButton_2_pressed to...
void MainWindow::on_pushButton_2_pressed ()
{
process->write("left\n");
process->waitForBytesWritten();
}
and change the child's source code to...
std::cout << "waiting for response..." << endl;
std::string input_line;
while (std::getline(std::cin, input_line)) {
std::cout << input_line << std::endl;
for(int i = 0; i<9999999; i++) {
}
}
return 0;
(All untested.)
As an aside, using Qt functions such as waitFoStarted, waitForBytesWritten etc. can be convenient but should be avoided. Far better to connect to and handle the various signals available.

Related

C++ no output, boost.asio

I'm about to write an IRCBot using Boost.Asio and I have the function getMsg:
std::string getMsg()
{
buffer.clear(); //make sure buffer is empty
buffer.resize(512); //make sure it's big enough for 512char
socket.read_some(boost::asio::buffer(&buffer[0],buffer.size()));
std::size_t pos = buffer.find("PING :");
if(pos != std::string::npos)
{
sendMsg("PONG :" + buffer.substr(pos + 6));
}
return buffer;
}
In my main function when using std::cout << Text; I get an output, but when trying std::cout << "Hello", nothing seems to happen:
while(true)
{
std::string Text = Test.getMsg();
std::cout << Text; //OUTPUT
}
while(true)
{
std::string Text = Test.getMsg();
std::cout << "TEST"; //NO OUTPUT ---- WHY?
}
The error you are asking about most likely occurs because you don't flush the stdout: std::cout << "TEST" << std::flush; This has nothing to do with boost::asio.
However your asio code also has a possible error: You are looking for PING : there in a single read call which might never be received within a single read call, due to the fact of how TCP works (it's a stream, not packets). If it's UDP socket it would work.

qt: How to send control command to POS printer?

I am creating an application which prints text through a POS printer.
The prints works fine. But for POS printer there are control commands to do certain functions like : paper cut, cashdraw open etc.. For eg:
Function: Partial cut
Code:
ASCII———-> ESC i
Hex ————-> 1B 69
Decimal—-> 27 105
When I try to send command 27 105 it just prints on paper instead of performing action.. I’m not exactly sure how to send it… Can someone suggest how to write to the socket…
#include "lanprinterui.h"
#include "ui_lanprinterui.h"
LanPrinterUI::LanPrinterUI(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::LanPrinterUI)
{
ui->setupUi(this);
m_TextInput = ui->textEdit;
m_pSocket = new QTcpSocket();
m_pSocket->connectToHost("192.168.1.20", 9100);
m_ConnectStatus = true;
QObject::connect(ui->pushButton, SIGNAL(clicked()), this, SLOT(print()));
}
LanPrinterUI::~LanPrinterUI()
{
delete ui;
delete m_pSocket;
}
void LanPrinterUI::print()
{
const int Timeout = 5 * 1000;
if (!m_ConnectStatus)
{
m_pSocket->connectToHost("192.168.1.20", 9100);
}
if (!m_pSocket->waitForConnected(Timeout))
{
//sent error
qDebug ("error in waitForConnected()");
qDebug (qPrintable(m_pSocket->errorString()));
m_ConnectStatus = false;
return;
}
m_ConnectStatus = true;
QByteArray block;
QDataStream out(&block, QIODevice::WriteOnly);
out.setVersion(QDataStream::Qt_4_0);
out << m_TextInput->toPlainText();
out << '\n';
m_pSocket->write(block);
}
What you want is
out << "\n\x1Bi";
That is, you want, after the '\n' char, to send the '\x1B' char (also known as "escape") and the 'i' char. You could also have written this as:
out << '\n' << "\x1b\x69";
or:
out << '\n' << char(27) << char(105);
or:
out << '\n' << char(0x1b) << char(0x69);
(or any other valid combination)
Another, better idea, would be to put in your class:
class LanPrinterUI {
private:
static const QString PARTIAL_PAPER_CUT = "\x1bi";
static const QString CASHDRAWER_OPEN = "\x1b....";
//...
};
And then you would just:
out << '\n' << PARTIAL_PAPER_CUT;
(which would be much better than hardcoded constants)

How to use QProcess write correctly?

I need a program to communicate with a subprocess that is relying on in- and
output. The problem is that I am apparently not able to use QProcess correctly.
The code further down should create a QProcess, start it and enter the main while loop. In there it prints all the output created by the subprocess to the console and subsequently asks the user for input which is then passed to the subprocess via write(...).
Originally I had two problems emerging from this scenario:
The printf's of the subprocess could not be read by the parent process.
scanf in the subprocess is not receiving the strings sent via write.
As for (1), I came to realize that this is a problem caused by the buffering of the subprocess' stdout. This problem can be solved easily with fflush(stdout) calls or manipulations regarding its flushing behavior.
The second problem is the one I can't wrap my head around. write gets called and even returns the correct number of sent bytes. The subprocess, however, is not continuing its excecution, because no new data is written to its output. The scanf seems not to be receiving the data sent. The output given by the program is:
Subprocess should have started.
124 bytes available!
Attempting to read:
Read: This is a simple demo application.
Read: It solely reads stdin and echoes its contents.
Read: Input exit to terminate.
Read: ---------
Awaiting user input: test
Written 5 bytes
No line to be read...
Awaiting user input:
I am seriously stuck right here. Google + heavy thinking having failed on me, I want to pass this on to you as my last beacon of hope. In case I am just failing to see the forest for all the trees, my apologies.
In case this information is necessary: I am working on 64bit MacOS X using Qt5 and the clang compiler. The subprocess-code is compiled with gcc on the same machine.
Thank you very much in advance,
NR
Main-Code:
int main() {
// Command to execute the subprocess
QString program = "./demo";
QProcess sub;
sub.start(program, QProcess::Unbuffered | QProcess::ReadWrite);
// Check, whether the subprocess is starting correctly.
if (!sub.waitForStarted()) {
std::cout << "Subprocess could not be started!" << std::endl;
sub.close();
return 99;
}
std::cout << "Subprocess should have started." << std::endl;
// Check, if the subprocess has written its starting message to the output.
if (!sub.waitForReadyRead()) {
std::cout << "No data available for reading. An error must have occurred." << std::endl;
sub.close();
return 99;
}
while (1) {
// Try to read the subprocess' output
if (!sub.canReadLine()) {
std::cout << "No line to be read..." << std::endl;
} else {
std::cout << sub.bytesAvailable() << " bytes available!" << std::endl;
std::cout << "Attempting to read..." << std::endl;
while (sub.canReadLine()) {
QByteArray output = sub.readLine();
std::cout << "Read: " << output.data();
}
}
std::cout << "Awaiting user input: ";
std::string input;
getline(std::cin, input);
if (input.compare("exit") == 0) break;
qint64 a = sub.write(input.c_str());
qint64 b = sub.write("\n");
sub.waitForBytesWritten();
std::cout << "Written " << a + b << " bytes" << std::endl;
}
std::cout << "Terminating..." << std::endl;
sub.close();
}
Subprocess-Code:
int main() {
printf("This is a simple demo application.\n");
printf("It reads stdin and echoes its contents.\n");
printf("Input \"exit\" to terminate.\n");
while (1) {
char str[256];
printf("Input: ");
fflush(stdout);
scanf("%s", str);
if (strcmp(str, "exit") == 0) return 0;
printf("> %s\n", str);
}
}
P.s: Since this is my first question on SO, please tell me if something is wrong concerning the asking style.
Solution
After many many more trials & errors, I managed to come up with a solution to the problem. Adding a call to waitForReadyRead() causes the main process to wait until new output is written by the subprocess. The working code is:
...
sub.waitForBytesWritten();
std::cout << "Written " << a + b << " bytes" << std::endl;
// Wait for new output
sub.waitForReadyRead();
...
I still don't have a clue why it works this way. I guess it somehow relates to the blocking of the main process by getline() vs blocking by waitForReadyRead(). To me it appears as if getline() blocks everything, including the subprocess, causing the scanf call never to be processed due to race conditions.
It would be great, if someone who understands could drop an explanation.
Thank you for your help :)
NR
This will not work. You are waiting for the sent bytes to be written but you are not waiting for the echo. Instead you are entering the getline() function waiting for new user input. Keep in mind that two processes are involved here where each process can be delayed to any degree.
Apart from this you should consider building your Qt application asynchronously (having an event loop) instead of trying the synchronous approach. This way your Qt application can do things in parallel... e.g. reading input or waiting for input from the remote process while still not being blocked and able to accept user input.

QSerialPort::readLine doesn't work as expected on MS Windows

I'm trying to connect a micro-controller with my desktop PC via USB-serial cable.
The OS of my desktop PC is Windows 8.1, and USB-serial cable is TTL-232R-3V3. (FTDI)
(Qt version: 5.2.0 beta1, QtCreator Version: 3.0, Compiler: MSVC2012)
Now I'm trying read/write loop-back tests, and that's why RX/TX pin of USB-serial cable are connected with each other.
Here is my code.
#include <QtCore/QCoreApplication>
#include <QtSerialPort/QSerialPort>
#include <QtSerialPort/QSerialPortInfo>
#include <QtCore/QDebug>
#define PORT_NAME "COM3"
#define BAUDRATE 19600
#define TIMEOUT_MS 1000
QT_USE_NAMESPACE
int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
QSerialPort pSerial(PORT_NAME);
const char strMsg[] = "#1:Send data line \n #2:Send data line\n #3:Send data line end\n";
char strBuf[256];
qint64 nByte;
if(pSerial.open(QIODevice::ReadWrite)){
pSerial.setBaudRate(BAUDRATE);
qDebug() << "OPEN PASS";
pSerial.write(strMsg);
pSerial.flush();
if(pSerial.waitForBytesWritten(TIMEOUT_MS)){
qDebug() << "WRITE PASS";
}
pSerial.waitForReadyRead(TIMEOUT_MS);
while(true){
if( pSerial.canReadLine()){
qDebug() << "CAN READ LINE";
nByte = pSerial.readLine(strBuf,sizeof(strBuf));
qDebug() << "Length: " << nByte;
qDebug() << "Read data: " << strBuf;
}
}
pSerial.close();
} else {
qDebug() << "OPEN FAIL\n";
}
return a.exec();
}
When the program starts to run, the result is different than I expected.
Only first line of sent data can be received. So, "Read data: #1 Send data line" is printed
on console. But the rest of sent data will never be received. Does anyone know why?
Any help would be appreciated.
Thanks in advance.
EDIT: I revised my code according to Papp's comment.Then it works as I expected.
All sent message has been received.
Does it mean I misunderstand the usage about readLine() or canReadLine()?
// while(true){
// if( pSerial.canReadLine()){
// qDebug() << "CAN READ LINE";
// nByte = pSerial.readLine(strBuf,sizeof(strBuf));
// qDebug() << "Length: " << nByte;
// qDebug() << "Read data: " << strBuf;
// }
// }
pSerial.waitForReadyRead(TIMEOUT_MS);
QByteArray readData = pSerial.readAll();
while (pSerial.waitForReadyRead(TIMEOUT_MS)) {
readData.append(pSerial.readAll());
}
qDebug() << "Read data: " << readData;
EDIT 2nd time : Following code also works for me.
while(true){
if( pSerial.waitForReadyRead(TIMEOUT_MS) && pSerial.canReadLine()){ // I revised this line
qDebug() << "CAN READ LINE";
nByte = pSerial.readLine(strBuf,sizeof(strBuf));
qDebug() << "Length: " << nByte;
qDebug() << "Read data: " << strBuf;
qDebug() << "Error Message: " << pSerial.errorString();
}
}
That is because you need to read in a loop like this:
QByteArray readData = serialPort.readAll();
while (serialPort.waitForReadyRead(5000))
readData.append(serialPort.readAll());
Please see the creadersync example for the details what I added to 5.2. You can also check the creaderasync example for non-blocking operation.
To be fair, we have not tested readLine that much, but it works for me on Unix, so does it on Windows for someone else.
The mistake that you've made is expecting to receive all the sent data when waitForReadyRead returns. When waitForReadyRead finishes, all you're guaranteed is some data being available to be read. It may be as little as one character, not necessarily a whole line.
The loop from your last modification is the almost correct way to do it. You should nest reading of the lines in a separate loop. The following code is how it should be done, and agrees with the semantics of QIODevice:
while (pSerial.waitForReadyRead(TIMEOUT_MS)) {
while (pSerial.canReadLine()) {
qDebug() << "NEW LINE";
QByteArray line = pSerial.readLine();
qDebug() << "Length: " << line.size();
qDebug() << "Read data: " << line;
qDebug() << "Error Message: " << pSerial.errorString();
}
}
qDebug << "TIMED OUT";
Note that none of this code should even run in the GUI thread. Ideally you should move it to a QObject, use the signals emitted by QIODevice (and thus QSerialPort), and move that object to a separate thread.
The GUI thread can sometimes block for long periods of time, it's not normally desirable to have it disturb the timeliness of your device communication. Similarly, you don't want device timeouts to block the GUI thread. Both are equally bad and are a very common source of bad user experience. Qt makes multithreading very easy - leverage it for your user's sake, and do it properly.
On Linux I have to do it this way to receive ASCII text ending with '\n'
QByteArray readData = pSerial.readAll();
while (readData[readData.length() - 1] != '\n') {
pSerial.waitForReadyRead(5000);
readData.append(pSerial.readAll());
}
QString result(readData);
QSerialPort::readLine() doesn't work for me either

how to restore std::cin to keyboard after using pipe?

Problematic code:
#include <array>
#include <iostream>
#include <cstring>
int main(int argc, char *argv[])
{
using namespace std;
cout << "Read from file:" << endl;
while (!cin.eof())
{
array<char, 16> l_array;
cin.read(l_array.data(), l_array.size());
cout.write(l_array.data(), cin.gcount());
}
cout << endl;
cout << "Read from keyboard:" << endl;
cin.rdbuf(cout.rdbuf());
while (!cin.eof())
{
array<char, 64> l_array;
memset(l_array.data(), 0, l_array.size());
cin.read(l_array.data(), l_array.size());
cout << "===== DATA =====" << endl;
cout << l_array.data() << endl;
cout << "================" << endl;
}
}
This is how i run my program:
./application < file.txt
I can read data from pipe without problems but when i want to read it again it is still asociated with pipe. I have no idea how to switch it back. I have found 'rdbuf' function which can change it, but I have no idea how to use it.
I only found examples when you stard with keyboard switch to file and back to keyboard.
Like here: http://www.cplusplus.com/reference/iostream/ios/rdbuf/
But i don't have streambuf remembered so I can't do it like they did. I want to write program which can read most of data from file, and ask only when something is missing or just to ask user in runtime about permision or something. All inside console under linux.
#EDIT
Thank you for help, I post solution
class RedirectCinToConsole
{
protected:
std::ifstream m_console;
std::streambuf *m_oldCin;
bool m_success;
public:
RedirectCinToConsole() :
m_oldCin(0),
m_success(false)
{
m_console.open("/dev/tty");
if (m_console.is_open())
{
m_success = true;
m_oldCin = std::cin.rdbuf(m_console.rdbuf());
}
}
virtual ~RedirectCinToConsole()
{
if (m_oldCin)
{
std::cin.rdbuf(m_oldCin);
}
m_console.close();
}
operator bool () const { return m_success; }
};
int main()
{
RedirectCinToConsole l_redirect;
if (l_redirect)
{
std::string l_helloWorld;
std::cin >> l_helloWorld;
std::cin.ignore();
std::cout << l_helloWorld;
}
return 0;
}
It occurs to me that, regardless of the proposed solutions, the easiest
solution (and probably the best) would be to do things the opposite:
don't redirect the input, but pass the filename to the program, and let
it open an std::ifstream to read it, keeping std::cin free for
interactive input.
Ben Voigt has suggested the standard Unix solution, but on thinking
about it, it seems the above is more natural; it is certainly easier and
more portable.
Perhaps you should use fstream to create your own stream and either ask for a file name or take the file name as a command-line parameter. This will leave cin available for other input operations.
Try opening /dev/tty. This will be your process's associated console, if there is any. If your process was started from a daemon, it could fail.