According to the help you can compile a QAction in debug mode:
Which additional information will we see? Will this use more resources? Is this advised in a Production environment?
Hi Jens, I believe the only advantage is that you get the line number where the exception is thrown. I'm not sure if this option will bring more load on the QAction or not (running in debug mode). So to be honest I wouldn't use it on a production environment.
Instead: if you define proper exception handling you should be able to easily spot where the issue comes from.
If you keep your exception handling consistent and always print the QAction ID, Method and full exception, this should be convenient to then troubleshoot for issues where needed. Good luck!
Did a quick test and it doesn’t seem like the debug preprocessor is being enabled. (Tested by adding 3 log lines embeded with “debug”, “Debug” and “DEBUG”)
By default, the DataMiner compilation engine compiles with the optimization level option set to Release. When specifying the debug option, the DataMiner compilation engine compiles with the optimization level option set to Debug, which disables all optimizations (and instruments the generated code to improve debugging experience).
In addition, when using this option, next to the DLL, a program database file (.pdb) will be generated. This way, you get more information when exceptions occur (e.g. line number).
In Visual Studio, by default, the Debug solution build configuration has the “Define DEBUG constant” enabled.
However, DataMiner does not add this preprocessor directive automatically when using the debug option.
Does this debug option also activate the DEBUG preprocessor directive?