Visual Studio testrunner still running … and stopping you from accessing DLLs for linking

Written by  on October 8, 2019

Problem Challenge:
Several instances of vstest.executionengine.clr20.exe are still running, despite closing that nice Visual Studio 2015 and therefore the access to compile and link several DLLs with QtCreator is blocked.
Closing them one by one with the taskmanager is annoying.

* CMD as admin
* $ taskkill /IM vstest.executionengine.clr20.exe /T /F
* or: $ wmic process where name=’vstest.executionengine.clr20.exe’ delete

Qt: Error: Not a signal or slot declaration

Written by  on September 4, 2019

This error is too ‘good’ to be just put into “Today I learned”.

While adapting some unit-testing-code for one of the classes, I received from minGW a error stating:

What is the problem? The member-declaration looked totally valid.
Until I realized I had removed the (now commented) “private”-statement and therefore the pointers were seen by the MOC as signals/slots. Which they weren’t!

Shame on me :’)

Advanced debugging: find call which triggers Qt-errors

Written by  on April 26, 2019

Currently the debugging version of the Qt-libraries is not available. But I receive a report "QIODevice::write (QIODevice): Called with maxSize < 0" deep within them.
Our codebase is quite large, I am more familiar with other sections and let's say it: some is 'legacy'. So, where to start looking?!?
Yesterday I remembered a trick to get via call-stack to the last-recent position where our functions trigger that mistake.

Inserted in the main.cpp after show from the MainWindow was called a

which stands for this

Add a breakpoint in the messageHandler and debug the app. Maybe disable the breakpoint until you start to trigger the critical functionality.
When it breaks, you have a nice callstack and can backtrace where it came from :)