Important: Please read the Qt Code of Conduct -

[Solved]Problem using low level I/O

  • Howdy:

    I'm porting this app to qt because I want to add a gui. The app does modem i/o and has been well debugged and working smoothly for several years.

    It uses "open, close, read, write, and select" to achieve communication with the modem. Everything ported very well with the exception of the close command. It seems that there is a name conflict with some other close statement that the gui stuff uses. Here's the results of my attempted build:
    09:06:28: Running steps for project CallMonitoring...
    09:06:28: Configuration unchanged, skipping qmake step.
    09:06:28: Starting: "/usr/bin/make"
    g++ -c -pipe -g -Wall -W -D_REENTRANT -fPIE -DQT_QML_DEBUG -DQT_DECLARATIVE_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I../../Qt/5.2.0/gcc_64/mkspecs/linux-g++ -I../CallMonitoring -I../../Qt/5.2.0/gcc_64/include -I../../Qt/5.2.0/gcc_64/include/QtWidgets -I../../Qt/5.2.0/gcc_64/include/QtGui -I../../Qt/5.2.0/gcc_64/include/QtCore -I. -I. -I. -o mainwindow.o ../CallMonitoring/mainwindow.cpp
    ../CallMonitoring/mainwindow.cpp: In destructor 'virtual MainWindow::~MainWindow()':
    ../CallMonitoring/mainwindow.cpp:152:13: error: no matching function for call to 'MainWindow::close(int&)'
    ../CallMonitoring/mainwindow.cpp:152:13: note: candidate is:
    In file included from ../../Qt/5.2.0/gcc_64/include/QtWidgets/qmainwindow.h:45:0,
    from ../../Qt/5.2.0/gcc_64/include/QtWidgets/QMainWindow:1,
    from ../CallMonitoring/mainwindow.h:4,
    from ../CallMonitoring/mainwindow.cpp:1:
    ../../Qt/5.2.0/gcc_64/include/QtWidgets/qwidget.h:478:10: note: bool QWidget::close()
    ../../Qt/5.2.0/gcc_64/include/QtWidgets/qwidget.h:478:10: note: candidate expects 0 arguments, 1 provided
    ../CallMonitoring/mainwindow.cpp: In member function 'void MainWindow::PollModem()':
    ../CallMonitoring/mainwindow.cpp:369:13: warning: unused variable 'j' [-Wunused-variable]
    make: *** [mainwindow.o] Error 1
    09:06:29: The process "/usr/bin/make" exited with code 2.
    Error while building/deploying project CallMonitoring (kit: Desktop Qt 5.2.0 GCC 64bit)
    When executing step 'Make'
    Here's the c++ source statements:
    delete ui;
    Any thoughts on how to easily work around this?

    Thanks in advance.

  • Lifetime Qt Champion


    You should use std::close or also port that part to Qt using QFile.

    Out of curiosity, why do you call QApplication::exit in your destructor ?

  • "You should use std::close or also port that part to Qt using QFile."

    Tried that, it gives me a diagnostic saying that close is not a part of std.

    "Out of curiosity, why do you call QApplication::exit in your destructor ?"

    Just my inexperience with qt showing. When I would terminate the app, the gui would remain. Adding the exit fixed that.

    Porting to QT using QFile, I would lose my non blocking reads via select.

  • Lifetime Qt Champion



  • Thank you, SGaist, that worked great. I appreciate it.

  • Lifetime Qt Champion

    You're welcome !

    If I may, you should rather have that IO part encapsulated in an object so you could reuse it for both your GUI and CLI version without duplicating the code

  • The GUI version of the program uses a QTimer to check the serial port for caller id information every 100 millisecionds. The timer provides a very neat and clean means of doing that. The CLI version implements that via "setitimer" and a self written interrupt handler.

    As a retired software engineer, I worked mainly in real time embedded systems which back then was primarily a c and assembler world. I got out before I got beyond the journeyman level as a c++ guy. Now I just write apps for my own use.

    This particular program addresses the problem that I have with telephone solicitors. My plan is, once the GUI is up and running, to discard the CLI version.

    Thank you again for your very clear and concise assistance.

  • Lifetime Qt Champion

    You're welcome !

    I'd keep the CLI and update it so it can still be used through e.g. ssh

  • Upon further reflection, you're definitely right about that.

Log in to reply