5

I'm wondering if it's possible to bypass the OutputDebugString? I'd like the OutputDebugString output showing up in DebugView and not in the internal Delphi Event Viewer window. But i can't find a way to tell Delphi not to swallow the OutputDebugString. Any ideas?

regards

devployment
  • 2,121
  • 1
  • 22
  • 33
  • 2
    It ought to show up in the Delphi Window _and_ in DebugView. Can you confirm that's happening? – H H Jun 25 '10 at 06:45
  • 2
    I've got Delphi 7 too and it is not showing in DebugView, only in the Delphi Event Log. – The_Fox Jun 25 '10 at 06:49
  • 2
    It's only showing in the Delphi Event Log if it's running in a debug session. If the app is started without attached debugger OutputDebugString is catched by DebugView. – devployment Jun 25 '10 at 06:55
  • AFAIK pnly one debugger at a time can receive OutputDebugString output –  Jun 25 '10 at 06:58

5 Answers5

5

That is not possible.

OutputDebugString sends string to debugger (as its name suggests). There can be only 1 active debugger per process. You run your application under Delphi - Delphi got the messages, since its a debugger. You run your application outside Delphi - DebugView can access them, since no debugger claimed it.

However: WHY do you need this? Just disable other types of events in Delphi event log - and you'll get the same functionality as DebugView has.

Alex
  • 5,477
  • 2
  • 36
  • 56
  • 1
    I know that the output is send to the debugger. My question is how to bypass it. But it looks like there's no way to bypass it. And i don't get the same functionality if i disable the other types. I'm still receiving hundreds of debug messages. In DebugView i can filter the output and thus i'll only see what i'm interested at the moment. That makes a huge difference. – devployment Jun 25 '10 at 08:30
  • 1
    @pantharhei: looking here http://d-fens.net/?idMenu=3&idSub=8&idPage=1&uLinkPages=1&uToc=0, it appears to me that it should be possible. The source code of the redirection is available from the author on request. – Lieven Keersmaekers Jun 25 '10 at 09:25
  • @Lieven: That looks interesting. Will have a closer look if the time pressure is gone. Will it ever be gone? ;) – devployment Jun 25 '10 at 09:42
  • I think that you're asking too much from this simple debugging routine. Try to look to other logging solutions, like ETW ( http://msdn.microsoft.com/en-us/library/bb968803(VS.85).aspx ) or SmartInspect ( http://www.gurock.com/smartinspect/ ) or anything else. – Alex Jun 25 '10 at 10:49
  • @Lieven Your link talks about different thing. It discusses tool, which acts as debugger reading output from OutputDebugString and transfer it to other session, where *actual* debugger is. There are 2 debuggers, each one is connected to *separate* sources. There are 2 sources and 2 debuggers. This is different from the situation in question, where pantarhei wants 2 debuggers (Delphi and DebugView) connect to *single* source. And you can't do that, since reading from source involves using *auto-reset* events. Once debugger use them - no other application can use them too for obvious reasons. – Alex Jun 25 '10 at 11:03
  • If I understand correct, pantarhei really only wants the output of OutputdebugString to go to DebugView. In the end, if it's a matter of capturing the right event, attaching to the right mutex, I'd gather it *might* be possible to write a tray application that *steals* the information passed on by OutputDebugString. – Lieven Keersmaekers Jun 25 '10 at 11:53
  • @Lieven Since Delphi already reads output of OutputDebugString - it's the same as reading from OutputDebugString by two independent applications. And this is not possible. If your application is going to wait on the same event, you will end up in random chaotic behaviour of having messages posted randomly to Delphi or your "hi-jack" application. You need either to ask Delphi to stop reading OutputDebugString (which is not possible) or ask it to cooperate with you (which is also not possible). I really do not see a way here. – Alex Jun 25 '10 at 12:52
  • Also note that protocol for OutputDebugString uses mutex to guarantee exclusive access to reading OutputDebugString by only one application. Sure, your application can just not respect this mutex and access buffer directly, but you still can't get notification about changes in reliable way. – Alex Jun 25 '10 at 12:54
  • @Alexander, I'm not going to argue about the inner workings, not really my cup of tea, but the line of text *redirects them to a debugger of your choice* implies to me that it should be possible. I didn't say it would be nice :) – Lieven Keersmaekers Jun 25 '10 at 13:57
  • @Lieven You read sentence out of context then. Full statement is "DbgViewRedir allows you to **monitor other sessions than your own** and either displays these messages in a console or redirects them to a debugger of your choice". Surely, *this* is possible. But it is far different thing that pantarhei asks. – Alex Jun 25 '10 at 14:05
1

I think there is no way around this. The situation is still the same in Delphi 2009. You should submit a feature request: http://qc.embarcadero.com

I'm wondering what the advantage instead of Delphi's internal event log window should be?

splash
  • 13,037
  • 1
  • 44
  • 67
  • The advantage is that you can filter the debug strings in DebugView. Makes the life much easier. – devployment Jun 25 '10 at 07:06
  • Do you really need more than the on/off filter in Delphi? ;-) – splash Jun 25 '10 at 07:08
  • Submitting a feature request for D7? Are you kidding me? I'm pretty sure that they are not going to add it do D7 if it isn't possible at the moment in D09. – devployment Jun 25 '10 at 08:33
  • Needless to say that I meant a feature request for future versions. It doesn't help you now, but it's a useful request. – splash Jun 25 '10 at 09:56
  • I'm pretty sure that way back in 1998 somebody said: "Submitting a feature request for D2? Are you kidding me? I'm pretty sure that they are not going to add it do D2 if it isn't possible at the moment in D4" :D That's why we still don't have this feature in D7 and D2010 and we'll never have it, since nobody cares about reporting it. – Alex Jun 25 '10 at 12:58
  • Play a little with QC and see how many big bugs and needed features are there since Delphi 6 or 7 and never taken care of, many still only in "reported" state. QC is useful, but it is true that if you report against an old version instead of the latest one your bug may never be looked at and opened. –  Jun 25 '10 at 13:53
  • The advantages of being able to redirect debug output when running a program in the IDE aren't limited to DebugView's filters. It would enable you to use [DebugView++](https://debugviewpp.wordpress.com/2014/01/04/7/), which has the same filtering capacity and adds highlighting of lines based on string matching (including RegExp), and it goes much faster than DebugView or the IDE debugger output. – rossmcm Aug 27 '17 at 21:33
1

Instead of DebugView you can try to use Process Monitor and its new "debug output" capability. It does not use OutputDebugString, it uses its own API, and there's also a Delphi wrapper here. You can use Process Monitor filtering features and Delphi won't trap that messages - but it's not a generic features as those of OutputDebugString.

  • Could use it for my own local tests. But i don't think that i will make it into the code base. But i'll take a look on it. Thanks. – devployment Jun 25 '10 at 14:41
0

Disabling "output messages" in the Event Log properties does not work?

  • 1
    Result is that the messages aren't displayed in the internal Event Log. But they're still swallowed by the debugger. – devployment Jun 25 '10 at 07:07
  • I am afraid the once a debugger it attached to a process Windows sends the output to that debugger. –  Jun 25 '10 at 09:30
0

Not what the original question asked, I realise, but it's worth taking a look at CodeSite from Raize Software. It takes OutputDebugString to a whole new level. Messages (can) get directed to a CodeSite viewer which is roughly equivalent to a highly souped up DebugView. Well worth every penny IMHO.

shunty
  • 3,699
  • 1
  • 22
  • 27
  • Sure. But it's not in my responsibility to order or introduce these tools. I've also looked at SmartInspect. Would be nice to have, for sure. But not at the moment. – devployment Jun 25 '10 at 09:40
  • On the contrary, Pantarhei, it's *everybody's* responsibility to introduce useful tools to their peers. – Rob Kennedy Jun 25 '10 at 12:15
  • Ok. Used the wrong words. So i introduced the tools already. But i can't decide if they will be bought and integrated into the existing tooling. – devployment Jun 25 '10 at 14:02