C++ Gurus

@SamiV123 , @JoeCFD @JonB @jsulm Thank you

i compiled it successfully using qmake.

@AnneRanch said in Another "reuse" question: **this message does not show anywhere** auto pC = new Console; // Original class auto pSB = new QStatusBar; // Additional status bar auto layout = new QVBoxLayout; layout->addWidget(pC); layout->addWidget(pSB); auto consoleWithStatusBar = new QWidget; consoleWithStatusBar->setLayout(layout); consoleWithStatusBar->show(); pSB->showMessage(" TEST status bar message ");

@inglis-dl adding: also tried variations on -I and -L path names such as / or \ separators as well as adding paths to windows system PATH envar

@JonB said in TEMPLATE = lib ?: that is not to do with you including or not including .h files in .cpp files. That has been discussed and concluded TRUE. Let's move on... It is to do with your code actually calling a function in another .o file and that not being passed to the linker to resolve. That is NOT the case - I have described how I use "add library" to add it to subproject .pro file - who is using it. Let's move on... I suspect the link to .so IS THE issue...

@jdent As @Christian-Ehrlicher says, who knows, behaviour may be compiler-specific and it does not claim to check everything, I think. My own guess is that the call to showing the dialog avoiding the detection may well be "coincidence", nothing to do with the specific call, many other things might cause it to skip. Under Ubuntu, Qt 5, gcc and .pro file having CONFIG+=sanitizer CONFIG+=sanitize_address it does report a SIGABRT on code like yours, whether I put in a QDialog and/or exec() or not. I do not know whether you can use those CONFIG lines from Qt with MSVC or not. One tiny thing: just in case MSVC is "optimizing out" your x code completely because it has no effect (e.g. gcc warns "unused variable"), add something which uses x after your code.

@AnneRanch UPDATE / GOTCHA When reusing (C++ "feature") project in subproject one better change / rename "MainWindow" class name. . I start with renaming the existing class header file. QtCreator gives an option to rename both .cpp and .ui BUT you must start with renaming the header file FIRST. Then you can rename the MainWindow class and that will change the "object" name in .ui file! l Another "GOTCHA" - the #include ui_ file , generated from .ui file MUST be changed manually ! Good luck...

@ItsRhysNotRhys In order to get from Printing Queue: 4 5 0 to 2 left in queue inside moveElevator1 Printing Queue: 3 5 0 something outside the code you are showing us (maybe in whatever issues two of those message lines) is writing 3 to queue[0]. Either directly, or just possibly through buffer over/underflow writing to another member variable adjacent to int queue[20] .

And to add to @Chris-Kawa: If you use C++11 or higher, you should init the members directly at their declaration: bool m_foo = false;. At least that's what I do. Regards

@SimonSchroeder Details! And as far as I know Denmark & Sweden are more or less the same country anyway ;-)

@JonB I guess both ways work. I do not have preference.

@Qt-embedded-developer app looks like using stack(not heap) memory. when classNamePtr is cleared, it will try to destroy &app and your app will crash likely.

@Qt-embedded-developer lmgtfy: https://doc.qt.io/qt-6/model-view-programming.html

@AnneRanch Anne, I explained both of these above. You ask for clarification but what can I say further to what In have written? Summary: The command you are issuing, gnome-terminal lsusb, is not and never has been the correct syntax to ask gnome-terminal to run a command. It ignores the lsusb completely and simply runs gnome-terminal. So you see an interactive terminal window sitting there instead. For Ubuntu the command should be gnome-terminal -- lsusb. That will open the window, run lsusb and close the window when that finishes. Which happens so quickly in milliseconds that you simply won't see anything, the window will open and close faster than you can see. Which is why I said if you were to run gnome-terminal -- find / -print you will get to see what actually is happening. You can try these outside of your Qt program from a terminal. If you invoke gnome-terminal, or any other "terminal" such as xterm, to run a command (such as lsusb) the terminal will attach its stdout to the window it opens. That means no matter what your calling program --- a Linux shell or a Qt application --- it will not receive or be able to access any output the command (lsusb or whatever) produces e.g. on its stdout. That will go to the terminal window and cannot be seen by the calling application. As per when we discussed this a year or two ago and I said then, if you want to be able to read back the output from, say, lsusb you must run it directly (as the command you tell QProcess to start) and not invoke any gnome-terminal or xterm or other terminal to run it.