I got error when execute code. I think it's not related to code. something is missing.
java.lang.IllegalStateException: Problem in some module which uses Window System: Window System API is required to be called from AWT thread only, see http://core.netbeans.org/proposals/threading/
You have flagged your post with JavaFX, so I assume you are talking about a JavaFX application. Every GUI update in the JavaFX-world is done on the JavaFX application thread. Your exception however indicates that you are using some AWT code in your program which has a different requirement. It must be run on AWT thread. So, the first thing you have to do is find out what this code is and then you have to make sure to call it on the right thread. You can use Platform.runLater() to put something on the JavaFX thread and SwingUtilities.invokeLater() to put something on the AWT thread.
Related
I am using Qt5 for off-screen rendering and have a segmentation fault when running inside Docker.
I have the code inside a c++ and calling the function via python using pybind11
This is the code causing the segfault
QSurfaceFormat glFormat;
glFormat.setVersion(3, 3);
glFormat.setProfile(QSurfaceFormat::CoreProfile);
glFormat.setRenderableType(QSurfaceFormat::OpenGL);
surface = new QOffscreenSurface();
surface->setFormat(glFormat);
surface->create(); // <-- Here
The exact error is :
QObject::connect: Cannot connect (null)::destroyed(QObject*) to QOffscreenSurface::screenDestroyed(QObject*)
I tried to run it via xvfb-run -a python prg.py and got the same error
Any pointers to debug this?
A little more context to the issue , the above code works fine if I use it inside main thread wrapped in QApplication. This problem occurs only when I move it inside a function so I can call it inside python.
Your last clue about running outside of the main thread is probably the problem you are running into.
Looking at the docs https://doc.qt.io/qt-5/qoffscreensurface.html#details:
Note: Due to the fact that QOffscreenSurface is backed by a QWindow on
some platforms, cross-platform applications must ensure that create()
is only called on the main (GUI) thread. The QOffscreenSurface is then
safe to be used with makeCurrent() on other threads, but the
initialization and destruction must always happen on the main (GUI)
thread.
So the solution would probably be to create the surface in the main thread and then just use it like you need it via pybind11.
I'm trying to migrate a program from java 8 to java 9.
In my program I found the following code.
//Run JavaFX Application Thread/Toolkit
PlatformImpl.startup(() -> {
});
It tries to start the JavaFX Toolkit
Unfortunately, the PlatformImpl.startup is no longer supported in java 9.
Which substitute is there for it?
How can I start the JavaFX Toolkit?
Thank you
The startup() method is one of the methods that was promoted from the non-public class PlatformImpl to the public API Platform class in the Java 9 release. It is now fully documented in the API documentation.
Thus the equivalent call in Java 9 is
Platform.startup(() -> { });
Note that the use cases for this method are fairly rare, and the API docs go to some lengths to emphasize this:
In general it is not necessary to explicitly call this method, since it is invoked as a consequence of how most JavaFX applications are built.
...
As noted, it is normally the case that the JavaFX Application Thread is started automatically. It is important that this method only be called when the JavaFX runtime has not yet been initialized. Situations where the JavaFX runtime is started automatically include:
For standard JavaFX applications that extend Application, and use either the Java launcher or one of the launch methods in the Application class to launch the application, the FX runtime is initialized automatically by the launcher before the Application class is loaded.
For Swing applications that use JFXPanel to display FX content, the FX runtime is initialized when the first JFXPanel instance is constructed.
For SWT application that use FXCanvas to display FX content, the FX runtime is initialized when the first FXCanvas instance is constructed.
When an application does not follow any of these common approaches, then it becomes the responsibility of the developer to manually start the JavaFX runtime by calling this startup method.
Calling this method when the JavaFX runtime is already running will result in an IllegalStateException being thrown - it is only valid to request that the JavaFX runtime be started once.
So, while you are in the process of making the changes you need to update your application to be Java 9 compatible, you might want to carefully consider if you need to call startup() at all; maybe there is a more standard and robust approach to starting your JavaFX application anyway.
My application has qml as frontend and c++ as backend.
To check some issues, I want to forcefully made qml to crash.
Mainly I am interested what error message comes up when qml crashes on client site so that we can handle those error better.
I have tried few things like assigning null values or null pointer on QML page but it doesnt make application crash.
From C++ side, I load application from QQmlApplicationEngine.
Any advice will be helpful.
You can use debug mode in Qt Creator.
And the application will stop when it crashes. Then, you can check your stack.
QML won't crash :)
You can't really make some pure QML/JavaScript code "crash", at least not the same way that you can shoot yourself in the foot in C++.
Remember than QML and JavaScript are interpreted, and any error will typically generate a QML warning. Something like:
qrc:/main.qml:33: ReferenceError: timer is not defined
This error will interrupt whatever operation you're performing in your local scope, maybe mess-up a few bindings or not do exactly what you expect, but it won't "crash" your QML application.
But you can always crash your app
If you expose some C++ component to your QML, you can technically crash your app from QML by triggering some buggy C++ code from your QML context. But this is the same thing as crashing your app from your C++ backend....
You can catch errors (locally)
When dealing with QML/JavaScript errors, you can catch these errors the same way you would in regular JavaScript code, using try { ... } catch(e) { ... } mechanism, as demonstrated in Catch QML error message
You can report errors (globally)
Even though not catastrophic, an error in your QML may impact the behaviour of your QML UI. One possible possible way to prevent this is to write tests for you UI where you exerce your QML components in various ways to ensure no errors ensue.
One trick we use in our test code (could work in production too), is to override the default log handler and watch out for QML errors and warnings. This allows us to test our QML components (do they behave as expected?) and also verify that no warnings were generated during these tests. The relevant documentation is available here: http://doc.qt.io/qt-5/qtglobal.html#qInstallMessageHandler
I'm instantiating QSystemDeviceInfo on a worker thread, but it causes a segfault.
int BatteryInfo::getLevel() {
QSystemDeviceInfo sysDevInfo; //segfault happens when I step on to this line
return sysDevInfo.batteryLevel();
}
Is the class thread-safe, or does the problem lie elsewhere?
EDIT: With further debugging I also noticed that native Symbian calls segfault as well.
Best regards
Me and my friend found this issue as well on Symbian Qt Mobilty 1.0. He reported an issue QtMobility access from multiple threads. As it says in the issue description Think this could be due to that some static members are created first time the QSystemDeviceInfo/QSystemNetworkInfo is created..
If you are using Qt Mobility 1.2 or only accessing QSystemDeviceInfo from one thread it's some other issue.
EDIT: One workaround for us was to make sure we created a QSystemDeviceInfo object in our main thread first but then we had some problems with not getting all signals.
Do you have capabilities set ?
QSystemDeviceInfo needs the 'ReadDeviceData' capability.You will need to sign your app to install on the device if you include this capability.
I am writing a plugin for another application. I want to support the plugin on multiple platforms, so I am strongly considering using Qt.
The plugin needs to be able to show some basic GUI. The plugin interface does not in any way handle GUI - it is just a simple DLL/shared library specified with a C-header file.
Can I use Qt inside such a shared library? The calling application might or might not be using Qt itself. Any hints on what to do? Do I need to run a QApplication event-loop in a separate thread? Or can I just call the event-loop myself while waiting for input? (I only need modal dialogs).
I don't think it is possible because you need to create the QApplication eventloop in the main thread.
Note that QCoreApplication::exec()
must always be called from the main
thread (the thread that executes
main()), not from a QThread. In GUI
applications, the main thread is also
called the GUI thread because it's the
only thread that is allowed to perform
GUI-related operations.