How to "wrap " text widgets in debug ?
-
So, you want code to appear when a preprocessor macro is defined, and totally disappear when that macro is undefined. Common requirement with a common solution:
#define TRACE 1 #ifdef TRACE #define qTRACEDebug(RANDOMCODE) RANDOMCODE ; #else #define qTRACEDebug(RANDOMCODE) # endif // In one place qTRACEDebug(ui->chat->append("TRACE initialized...")) // In another qTRACEDebug(ui->blah->append("TRACE in the blah area..."))Experiment here: https://godbolt.org/z/3j8sacj4K
Then all you need to be careful about is that "RANDOMCODE" does not break macro expansion.
-
I need to look at the definition of qDebug macro...
( I need more time to do so )
I was not looking for replacing qDebug macro with another one.Here is SOME explanation of qDebug macro
https://stackoverflow.com/questions/34690328/how-does-qtdebug-syntax-work
That leads me to believe IT shud be able to get addition l info from qDebug -0 such as "line #" where qDebug is codded... maybe later... -
Update
It looks that the original syntax with " <<" should work.
It works with "tab widget": , but fails with
"text edit"What is the difference ?
qDebug() << "TEST qDebug: " << ui->tabWidget->tabText(testIndex ).append("TEST"); WORKS FINE
qDebug() << "TEST qDebug: " << ui->tabWidget->tabText(testIndex );
qDebug() << "TEST qDebug: " << ui->textEdit;qDebug() << "TEST qDebug: " << ui->textEdit->append("TEST TRACE debug "); FAILS
/media/q5/MDI/QT_PROGRAMS/LoCAL_SOURCE/HCI/form.cpp:513: error: invalid operands to binary expression ('QDebug' and 'void')
-
tabText returns a QString.
append returns void. -
#define WidgetLogEnabled #ifdef WidgetLogEnabled #define Log(text,widget) widget->append(text); \ qDebug()<<text // log to the console also #else #define Log(text,widget) qDebug()<<text #endif@mpergand Thank you for providing the solution to the "text" widget.
I was bedding to wonder if the whole idea needs to be ditched.
However, I have learn long time ago that "functions" better return something - just to keep code honest. My opinion is that this kind of "hiding" or not returning anything was not part of the OOP. ( Just an opinion,,,)
Cheers -
Wouldnt that lead to errors when TRACE is not defined and you still have
qTRACEDebugin your code?!
(because there's no TraceDebug?!)@Pl45m4 No. If TRACE is defined then the macro is defined to expand to the content of the macro argument, and if TRACE is undef then the preprocessor macro is defined to be a no-op. Either way, the entire macro is replaced in the output. So this:
foo; qTRACEDebug(ui->chat->append("TRACE initialized...")) bar;where the entire second line is the macro, becomes this after the pre-processor stage:
foo; bar;This achieves exactly what the OP asked for which was, as usual, not what the OP actually wanted.
-
@Pl45m4 No. If TRACE is defined then the macro is defined to expand to the content of the macro argument, and if TRACE is undef then the preprocessor macro is defined to be a no-op. Either way, the entire macro is replaced in the output. So this:
foo; qTRACEDebug(ui->chat->append("TRACE initialized...")) bar;where the entire second line is the macro, becomes this after the pre-processor stage:
foo; bar;This achieves exactly what the OP asked for which was, as usual, not what the OP actually wanted.
@ChrisW67
Yes, but one tiny, brief point. I would rather you defined your#elsecase as, say,#define qTRACEDebug(RANDOMCODE) ;or made both routes use{...}. Cf. typical definitions of assert-type macros. At the moment your code means thatif (condition) qTRACEDebug(...) ...succeeds when
TRACEis defined but syntax errors, or worse has unexpected behaviour, when it is not? -
@ChrisW67
Yes, but one tiny, brief point. I would rather you defined your#elsecase as, say,#define qTRACEDebug(RANDOMCODE) ;or made both routes use{...}. Cf. typical definitions of assert-type macros. At the moment your code means thatif (condition) qTRACEDebug(...) ...succeeds when
TRACEis defined but syntax errors, or worse has unexpected behaviour, when it is not?@JonB While you are correct with regards to the use of {}, I would say that the real issue here is not using the infrastructure that is already available.
Using a custom message handler that will then feed the widget with all the debug messages (or only a subset of one) would avoid making the code messy with that kind of stuff. This would also allow to have one dedicated text widget that would show the messages rather than mixing standard and debug messages in the GUI but that's an other topic.
-
@mpergand Thank you for providing the solution to the "text" widget.
I was bedding to wonder if the whole idea needs to be ditched.
However, I have learn long time ago that "functions" better return something - just to keep code honest. My opinion is that this kind of "hiding" or not returning anything was not part of the OOP. ( Just an opinion,,,)
Cheers@AnneRanch said in How to "wrap " text widgets in debug ?:
I was bedding to wonder if the whole idea needs to be ditched.
I'm very closed to think the same ;)
If you want special logging mecanism, you can use a dedicated widget for that or save them to a file that you can consult later on.
-
@AnneRanch said in How to "wrap " text widgets in debug ?:
I was bedding to wonder if the whole idea needs to be ditched.
I'm very closed to think the same ;)
If you want special logging mecanism, you can use a dedicated widget for that or save them to a file that you can consult later on.
@mpergand Yes, decided against the whole idea "interleaving" debug trace with output. It actually came as a way to bypass QtDesigner "break layout" .
Doing so I always come up with weird, unwanted layout.
Now I do copy the original layout and can recover...
Now I put output in one tab and debug TRACE in another. Then user can choose to observe the TRACE if he desires so.
I still think the qDebug is a decent tool and needs for additional preprocessor macros is debatable..Cheers
