I have written a Qt GUI application using Qt5 on Fedora 29. The application, which uses all kinds of Qt widgets, works as intended, but when I run it from the command line, I'm inundated with errors (like the one below) on the console:
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 4225, resource id: 36071117, major code: 40 (TranslateCoords), minor code: 0
For example, if I have a simple QMessageBox, with a simple text message and one "OK" push button, clicking on that OK push button will close the message box (as expected) and ALWAYS print out the error above.
{
QMessageBox::critical(this, "Title", "Fatal Error");
}
When I google these errors, I see people saying that these messages are harmless and that they can be safely ignored, but I find it hard to believe that Qt would make the effort of printing these messages if nothing is wrong.
Does anyone know what these messages mean and what I can do to get rid of them?
For the first part of your question, as Nikos C. has commented above, this is a bug in Qt.
You can always suppress diagnostic output of Qt. That has been answered some years ago: How to redirect qDebug, qWarning, qCritical etc output?
There are a few exceptional messages that can't be suppressed (e. g. qSetGlobalQHashSeed uses printf for warnings), but these are very rare.
Related
We are using Progress OpenEdge 10.2A for years and for the last 4 months we begin to receive unknown error messages from our customers.
We call our .w files using lines as follows:
RUN VALUE(myPath + "myProgram.r") PERSISTENT SET myPrograms[i].
Normally the same program calls work without any problem, but on rare occasions, the program window seems to get unresponsive, but in fact when we look at the windows taskbar, there is another entry in the taskbar which is a prowin32.exe window having title "Error". But when selected, there seems to have no visible window attached to it.
When we close it from the taskbar using Close Window option, it appears again in the taskbar 6-7 times again and then whole prowin32 session restarts.
We could not identify the error since it does not show any message or any error number.
If you encounter such a problem, I'd like to know how you solved it.
If not, it would be appreciated if you direct me to the way to solve the problem.
Edit 1:
After adding -errorstack -debugalert -clientlog myLogFile.log to my startup parameters, myLogFile.log is generated. The below part is written when the error occured.
**Unable to realise TEXT myText. (4025)
** ABL Debug-Alert Stack Trace **
--> enable_UI c:\myFolder\myFile1.r (c:\myFolder\myFile1.r) at line 21014
c:\myFolder\myFile1.r (c:\myFolder\myFile1.r) at line 14858
USER-INTERFACE-TRIGGER c:\myFolder\myFile2.r (c:\myFolder\myFile2.r) at line 2905
0) OpenEdge 10.2a is ancient, obsolete and unsupported. You should have moved to a modern release 10 years ago. At the very minimum you should be on 10.2b08. Do you also refuse to update Windows? OpenEdge 12 is the current release. It is possible, perhaps even likely, that unanticipated changes in Windows or other aspects of the environment are causing your problem. Progress is never going to update 10.2a to accommodate that sort of thing. You are just prolonging the agony by staying on an obsolete release.
1) What changed in your code or your environment 4 months ago?
2) You can get a stack trace for the extra prowin32 session by running proGetStack. That should help to explain what was launched, what the error is and why another 6-7 start after you kill it. Open a "proenv" window as "Administrator" and run proGetStack (you can get the process id from taskmgr).
proenv> proGetStack 123456
The stack trace will appear in the working directory of the target process. That is usually the same directory that proenv is in but it is possible that the application changes it so you might have to go hunting for it. (Administrator proenv windows sometimes do not start in %wrkdir%, you may also need to cd /d %wrkdir%)
3) If they are not already present you should add -debugalert and -errorstack to your client startup parameters. -clientlog logfileName.log would probably also be helpful.
4) Examine your code base for bits that invoke prowin32 sub-processes. There are many ways to do this such as OS-COMMAND, INPUT THROUGH or via Windows DLL calls. Directly invoking prowin32 can be found by searching for that string but it might also be indirect invocations via a BAT file or other technique.
5) if you have a repeatable way to produce the error then you could also add the 4GLTrace log entry type either at startup or in the code when you get to the proper point: https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/dpspr/log-entry-types-(-logentrytypes).html
I use squish-4.2.2 for testing GUI of our tool and use purecov.i386_linux2.7.3 for covering them. Our tools are based on qt-4.7.4_qsci version of QT. After building our tools in Purecov mode, when we run our tests, they fail if tests contain operation with "popsup menu". Purecov cannot generate the result *.pcv file. Also I would like to note that our tools do not fail when they are run without Squish, however "Popsup Menu" opens not earlier than after 30-60 seconds (in normal mode it is done during 1-2 seconds).
So I have 2 issues:
1. when tests are run with Squish, they fail when tests contain operation with "Menu" item;
2. Purecov does not generate *.pcv file when tests fail.
I tried to find some interesting things on your site for resolving those problems, but I couldn't find anything related to my issues.
In my opinion, Squish failed because when I try to open "Menu" item, GUI runs faster than its logic part, and after opening "Menu" item, Squish considers that operation is done and kills my tool.
Could you please tell me what I can do with my tests or tools for resolving those problems?
Thanks.
I had a similar issue in the past, with clicking menus from my app.
I hope this helps you also!
Example:
I wanted to open a "File" menu, followed by a sub-menu (which is pop-up) "New". When I'm in record mode of Squish, Squish records the following code in python:
activateItem(waitForObjectItem(":MainWindowForm.m_poMainMenu_QMenuBar", "File"))
activateItem(waitForObjectItem(":MainWindowForm.menuFile_QMenu", "New..."))
Now, this didn't worked all the time, honestly I didn't managed to understand why :).
But, I found on their site, this a possible solution. So, I've replaced Symbolic names from the code above, and created a function that calls the objects after Real name properties:
def callMenu(menu_name, submenu_name):
activateItem(waitForObjectItem("{type='QMenuBar' visible='true'}", menu_name))
activateItem(waitForObjectItem("{type='QMenu' title='%s'}" % menu_name, submenu_name))
After I made this change, the tests run smooth, without anymore problems (at least from the menu side).
I'm doing development for Blackberry 10 using Cascades, which includes QT and QML. I find that I sometimes make mistakes in my QML file, but they don't get picked up at compilation time. How can I check whether I've made a syntax error, or mis-named a function call, or other typical errors?
QML is a dynamic language that is evaluated at Runtime. There is no compilation step and due to the nature of javascript and the dynamic nature of the global context there is no way for it to tell if what you are writing is correct/incorrect until it is evaluated. QtCreator can help with some of the QML errors you will find, but there is unfortunately no good way to get syntax errors about your javascript until it is evaluated and it explodes.
Personally, I have found good usage of the debugger to be the key to making these sort of fixes easy.
tldr; Keep your javascript clean and to a minimum there is no compile time checking.
open terminal in IDE connect your device or emulator using blackberry-SSH after connecting enter slog2info it show syntax and all typical error JavaScript with description and line NO.
If there are any mistakes it will show those lines in RED marks. It is dynamically checks there is no need to worry about compile.
If you done wrong you will not see the DESIGN CONSOLE correctly.
Going through the phantomJS code i ran into this in the webpage.cpp file (line 315)
connect(m_networkAccessManager, SIGNAL(resourceRequested(QVariant)),
SIGNAL(resourceRequested(QVariant)));
And i don't quite understand how this works, i'm aware that you can connect signals to signals in Qt.
On the Qt documentation i found out that you can also connect signals directly to a method (http://doc.qt.io/qt-5/qobject.html#connect-2) , seeing that it's a 3 parameters call i thought that this would be the desired function on the webpage.cpp code, but connecting a signal to the same signal...i got completely lost there, any help?
PD: not very experienced in Qt i should say, sorry if it's a dumb question
Three parameters QObject::connect()
connect(m_networkAccessManager, SIGNAL(resourceRequested(QVariant)),
SIGNAL(resourceRequested(QVariant)));
is an equivalent of
connect(m_networkAccessManager, SIGNAL(resourceRequested(QVariant)),
this, SIGNAL(resourceRequested(QVariant)));
Thus, QNetworkAccessManager::resourceRequested(QVariant) is connected to WebPage::resourceRequested(QVariant) and cause the latter to be emitted every time when the former is emitted.
More details in Qt documentation
I´m trying to integrate googletest with my Qt Creator.
Basically I´ve got a googletest-listener, which evaluates my unit tests and prints the results to stdout. Now I´m trying to make that listener a build step, so it tells me when a test didn´t succeed. The results are now shown in the "Compile Output" tab.
What I want to do now is that the results are shown in the "Build Problems" tab as well. Just like normal build errors. Is this somehow possible without using a Creator-plugin?
EDIT:
In the meantime I´ve found the solution: It seems like Qt Creator takes all the "build problems" from stderr instead of stdout. So I just wrote my errors to stderr and now it works.
No, the build output is specifically made to catch compile and link errors, which Qt Creator links to the relevant parts of the source code when you click on the items in this list. Compile output is the full output of things like [n]make or msbuild build tools. Custom build steps only show here, with a plugin, you could of course do all kinds of magic (I have no experience here, but as everything in Qt Creator is a plugin, it should be very possible).