For testing during debug is there a way of conditionally logging or messaging to something like a console window?
For testing during debug is there a way of conditionally logging or messaging to something like a console window?
Rather than writing to a text log which is what I currently do.
Rather than writing to a text log which is what I currently do.
CodeSite is very good.
ReplyDeleteDebugout and debugview nativ microsoft.
ReplyDeleteWhen debugging in the IDE, you can use the extended breakpoint properties to evaluate expressions and write log messages to the event log. http://edn.embarcadero.com/article/31263
ReplyDeleteOutside the IDE there is e.g. the GExperts debug window and the associated send functions http://www.gexperts.org/tour/index.html?debug_window.html
Also, you always have the option to create a console application and use Write / Writeln.
{$IFDEF DEBUG}
ReplyDeleteAllocConsole; // Winapi.Windows
WriteLn('Debug mode');
{$ENDIF}
Our SynLog Open Source unit allows conditional logging, with optional remote access. See http://synopse.info/files/html/Synopse%20mORMot%20Framework%20SAD%201.18.html#TITL_16
ReplyDeleteOutputDebugString will write to the messages window.
ReplyDeleteBill Meyer I prefer SmartInspect but yeah very similar. It's unbelievable how many people are still using OutputDebugString or Writeln... OMG
ReplyDelete+1 for SmartInspect
ReplyDeleteStefan Glienke WriteLn is king :P quick and easy, and if you write GUI apps then you likely got the console window all for yourself.
ReplyDeleteStefan Glienke Much of my work is in reporting, and production of spreadsheets. I find logging can give me a sense of the problem much more quickly than can the debugger. Not always the case, but if I am digging into legacy code, the high repetition rate of code in these things can make it difficult to see the real issues. With logging, I am looking at patterns.
ReplyDeleteUse the tiLog, tiLogToConsole, tiLogToGUI and tiLogToFile etc units from the tiOPF project [http://tiopf.sourceforge.net]. Even though your project is not tiOPF based, the logging functionality can be used with any application and toggled from the command line. I find it immensely useful for debugging.
ReplyDeleteBill Meyer Why are you telling me? ;)
ReplyDeleteThanks for all the tips.
ReplyDeleteFor a quick debug session in production environment I like my colored console log https://goo.gl/photos/v1FGsKAU2ngy6qNw6
ReplyDeleteDo not use OutputDebugString, it will mess with your head. It doesn't handlie unicode properly (well in can since vista, but you have to call another function to indicate to the debugger that you want it to handle unicode), it uses a mutex internally which can really mess with thread timing etc. It also uses a shared 4K buffer which can result in your application blocking. There are better ways as others have pointed out.
ReplyDeleteCodeSite is another tool for logging.
ReplyDelete+1 for SmartInspect
ReplyDeleteVincent Parrett- Which other function do you call for unicode handling? We use it extensively (combined with logging to file in a separate thread), and I can't say I have seen any issues with Unicode?
ReplyDeleteNote that console/writeln logging tends to slow down the process a lot. Do not use a TMemo either, which could be very slow. A memory buffer with a virtual TList pointing to it is the faster option for UI logging.
ReplyDeletePaul TOTH I use CodeSite, but AllocConsole() sounds like a quick and clean method. Thanks!
ReplyDeleteA. Bouchez : Indeed, and that is why tiOPF's logging has built-in cache for its various log outputs. It also runs in a separate thread, so it doesn't slow down you application even you you throw 100's of log calls to it per second.
ReplyDeleteLars Fosdal WaitForDebugEventEx - see https://msdn.microsoft.com/en-us/library/windows/desktop/aa363362(v=vs.85).aspx
ReplyDelete