I have some legacy code which has been running on an older Qt version where QList still had an autodelete feature on pointers (at least that's what the in-code comments said). So the GUI was passed pointers to data objects, stored them inside some Qt container and was responsible for deleting them appropriately when sth (user or internal signal) triggered a Qt event for deleting one of the data objects. With the auto deletion feature this seems to have worked smoothly but now that it's gone I'm running into memory problems under Qt5.
It seems like I somehow have to synchronize the deletion with the Qt message loop because it's every time triggered from within a slot. If I just hard delete it by myself, the program will crash at some point because pending Qt events try to access the deleted data when it's already gone.
I think deleteLater would already do the trick, however the objects in question are derived from QTableWidgetItem and thus don't own a deleteLater slot.
Related
I am updating a VSIX extension that triggers a build to generate the .vcxproj.filters file.
I would like this to run as early as possible after loading the solution.
If the extension is already loaded, I can do this in the OnBeforeOpenProject method in a class derived from IVsSolutionLoadManager.
However, as extensions are now loaded asynchronously, if the solution was opened directly, then the extension doesn't load until some time after the solution. I can trigger the build in this case, but it cannot start the build as there is one already running, raising System.InvalidOperationException: 'The operation cannot be completed because a build is already in progress.'
I assume that Intellisense or similar is busy running a build in the background.
Ideally I would like to query the system in an async method to detect when this build has finished, so I can trigger my own build.
I could of course handle the exception and retry on a short timer, which I may also do, but I'd like to wait until I'm likely to succeed before trying.
My search-fu has failed me, so: how can I detect that VS is currently building?
Thanks.
I am attempting to use QTCreator's Memcheck tool to analyze the memory of a QT project, which is a dynamic library. It uses a QT Gui (QMainWindow) to allow the user to select a file, which is then processed, and then eventually returns to the mainwindow.
However, I cannot seem to use Memcheck properly.
When I select "Memcheck" and hit run, it instantly goes to "Analyzing memory" without ever letting the Gui pop up.
This is problematic. How can I get memcheck to work with this program?
I had two main issues:
1: Valgrind does not seem to play nice with QT Gui applications. It generates logs that are thousands of entries long for all the work QT is doing before it even gets to my application.
I had to make a separate, small non-GUI C++ program that would drive instead of the GUI application.
2: When trying to run from the command line, I needed to set an environment variable by using export. This needs to be the same as LD_LIBRARY_PATHS in QT Creator.
So I ran:
export LD_LIBRARY_PATH=X where X was the exact value I copied from LD_LIBRARY_PATHS in the variable from the QT Project.
Note: Running from the command line may have not be neccesary now that it isn't a GUI Application, memcheck might have passed just fine. Haven't tested since.
Basically, I'm trying to carry out a number of tasks while a Visual Studio instance is running.
I have not been able to find anything yet in the Visual Studio SDK reference which is analogous to a background thread or IsRunning or anything like that. All I can do so far is respond to very specific events such as the view changing or the cursor being moved.
I don't even understand what event fires when the Visual Studio instance finishes loading.
Surely there must be something pretty big that I'm missing here? What manages the lifecycle of a Visual Studio instance?
So nothing prevents you from launching a background thread and doing work there. All sorts of components do that all the time. There are some ways you can register your package to load in various scenarios, and from there you could always launch a thread.
Be careful of course with any of these -- if everybody did "I'll run a background thread once VS loads", your CPU cores would be very, very busy! There's an older concept in VS called the "idle loop" where some code can be registered to run whenever the UI thread doesn't have a message to pump, and the internal joke is that the idle loop is never idle.
I am working on a QT application for which I've integrated DirectX 11 into a custom widget. The application renders a scrolling display - a graphical representation of data being read from a file. The user can speed up and slow down the scrolling speed.
For the most part, this is working great. The DirectX 11 rendering is presented to my custom widget just as I'd expect. The problem is that the graphics driver randomly hangs and crashes my program. I say "random" because I have been testing this with the same data file and it never seems to crash at the same point in the file, after a specific amount of time, or at a specific scrolling speed (the faster the scrolling speed, the more work being done by the GPU per frame).
When the application hangs, my screen freezes for a moment, goes black, then returns with a nice message from NVidia that it has recovered from a driver crash. The Debug Output in Visual Studio contains the following:
D3D11: Removing Device.
D3D11 ERROR: ID3D11Device::RemoveDevice:
Device removal has been triggered for the following reason
(DXGI_ERROR_DEVICE_HUNG: The Device took an unreasonable amount of
time to execute its commands, or the hardware crashed/hung. As a
result, the TDR (Timeout Detection and Recovery) mechanism has been
triggered. The current Device Context was executing commands when the
hang occurred. The application may want to respawn and fallback to
less aggressive use of the display hardware). [ EXECUTION ERROR #378:
DEVICE_REMOVAL_PROCESS_AT_FAULT]
I have discovered that by simply commenting out the IDXGISwapChain1::Present call, the application will run through the file at blazing speed. Graphics-wise it is still pushing data to the GPU and drawing to render targets, it just never gets displayed to my window.
What I'm hoping for is help with ideas of what types of things cause driver hangs. My shaders are incredibly simple - basically just positioning my vertices using a projection matrix. And considering what I described in the above paragraph, shaders should still be cranking through vertices and pixels even when Present isn't being called, yes?
I was suspicious that this could be a compatibility issue with Qt - I know DirectX isn't officially supported by Qt. So I tried creating a separate window using CreateWindowEx and using that for my swap chain instead of the custom Qt widget. It rendered to that window but also hung the driver just like before.
I was also suspicious of a driver bug in my laptop, so I tried running the application on a beefier desktop PC that regularly runs another DirectX 11 application (non-Qt) without a hitch (worth mentioning that this other application renders similar data in a scrolling display as well, using shaders that are a lot more complex). But my QT application hangs the driver on that PC as well.
Anyone know of a way I can get a more detailed description of what is causing the driver to hang?
Thank you in advance for any help you can offer.
UPDATE: 2013-08-01 17:16 CST
I am currently investigating a possible thread syncing issue that may be the culprit. Will continue tomorrow morning and post if I solve this on my own.
After some testing today, it appears to have been a threading issue. I have run several times today with no graphics crash. So my problem must be fixed, unless I've just been getting lucky with my tests today (or unlucky, rather - if this shows its ugly face again in a day or two).
I was aware that the immediate device context is not thread safe. Rather than using deferred contexts, though, I was using critical sections to sync my threads and coordinate use of the device context. What I did not realize is that it is not safe to call IDXGISwapChain1::Present while another thread is using the device context. Makes sense, but since it is not call directly from the device context itself, I overlooked it. I literally moved my Present() call a few lines up into my critical section block, and it hasn't given me a crash since.
Can someone help me understand what are the problems in running multiple QApplications on Qt for Embedded Linux? Please point me to some documentation of mailing-list threads.
While going through some of the mails in mailing lists, I have seen some comments which say that, running multiple QApplications in Qt is not supported by design and why at all it is required? How can I understand this more clearly?
However, while reading the document "Qt for Embedded Linux Architecture" I did not find anything which says that we should not run multiple QApplication instances at the same time.
I am executing two QApplications on a Embedded Linux platform (not a PC) and one of them in full screen mode. The one which is in fullScreen mode it is not getting keyboard focus, even though it receives mousePress events. If same app is run in normalMode, it gets the mousePress event followed by focusInEvent`.
Can somebody provide pointers on it?
You can run multiple processes each with one QApplication just fine.
However, with Qt for Embedded Linux, only one of these must be the QWS server. In other words, you should start the first process with `-qws', and all other processes without.
QApplication is a singleton class, so its "single" by design. You can have only a single QApplication object per program.
But in Qt there is no inherent limitation of the number of qt programs using the QApplication class you can run parallel. You can have more than one program using qt (and thus very likely QApplication) at the same time.
Probably this got somehow confused in your mailing lists.
My guess is that one QApplication would accept the mouse event or keyboard event and therefore the other would not get it.
Its probably a little random as to which QApplication accepts which events based on having so many QApplications in a single process.
I cannot imagine the use case as to why you would want multiple QApplications within a process. Could you expand on what you are trying to do?