libQCR issueshttps://jugit.fz-juelich.de/mlz/libqcr/-/issues2024-02-14T16:00:20+01:00https://jugit.fz-juelich.de/mlz/libqcr/-/issues/2ctest must not run against installed library2024-02-14T16:00:20+01:00Wuttke, Joachimj.wuttke@fz-juelich.dectest must not run against installed libraryfrom Joachim, [see here](https://jugit.fz-juelich.de/mlz/libqcr/-/issues/2#note_385870)
~~~
This is a long-standing issue that resurfaces over and again in different projects. You do make, ctest,
make install. Then you modify the code, ...from Joachim, [see here](https://jugit.fz-juelich.de/mlz/libqcr/-/issues/2#note_385870)
~~~
This is a long-standing issue that resurfaces over and again in different projects. You do make, ctest,
make install. Then you modify the code, do make, ctest, make install again - and your code is broken.
Why? Because the second time you run ctest, it executes using the *installed* library, not the latest,
modified version from your build/lib directory, and so you overlooked a fatal bug your modfication
introduced in the library.
As a developer, I can generally avoid this issue by having the relative path `lib` in the beginning of my
`LD_LIBRARY_PATH`. But as library maintainers, couldn't we also do something to prevent this kind of error?
~~~https://jugit.fz-juelich.de/mlz/libqcr/-/issues/6Missing GUI element: Boolean state indicator2024-01-22T11:06:33+01:00Christian TrageserMissing GUI element: Boolean state indicatorLibqcr is missing an GUI element which shows an boolean state (without the ability of chaning it by the user).
As far as I know most often these functionality has been implemented by using an read-only checkbox element. But libqcr should...Libqcr is missing an GUI element which shows an boolean state (without the ability of chaning it by the user).
As far as I know most often these functionality has been implemented by using an read-only checkbox element. But libqcr should have its own element.https://jugit.fz-juelich.de/mlz/libqcr/-/issues/9Linking Issues when gLogger is connected via QObject::connect under windows2024-02-14T13:44:48+01:00Christian TrageserLinking Issues when gLogger is connected via QObject::connect under windowsThis has been first seen with this (now replaced) `utest/10_logger.cpp` TEST. The linking issues arise from `QObject::connect`. This seem to only occur under windows while under linux this works perfectly fine.
~~~
#include "QCR/engine/l...This has been first seen with this (now replaced) `utest/10_logger.cpp` TEST. The linking issues arise from `QObject::connect`. This seem to only occur under windows while under linux this works perfectly fine.
~~~
#include "QCR/engine/logger.h"
#include "catch.hpp"
TEST_CASE("QcrLogger", "[signal]")
{
gLogger = new QcrLogger("10.log");
QString lastReceived;
QObject::connect(gLogger, &QcrLogger::sigLine, [&lastReceived](const QString& received) {
lastReceived = received;
});
gLogger->log("bla1");
CHECK(lastReceived == "bla1");
}
~~~
This issue can be reproduced. For example in `demo/demo1_triggerbutton.cpp`. If a connection with a signal is inserted in this file then the same linking errors appear.