search

CobaltFusion / DebugViewPP

DebugView++, collects, views, filters your application logs, and highlights information that is important to you!
Boost Software License 1.0
1.02k stars 150 forks source link

Feedback on Debugview++ #283

Open janwilmans opened 7 years ago

janwilmans commented 7 years ago
hoppfrosch commented 7 years ago

Love it! Use it nearly every day without any complaint yet and it works llike a flaw. I don't have feature requests ATM.

SteeleDynamics commented 7 years ago

No issues so far, but I haven't had a lot of opportunities to use it at home or work. The last time I used it at work, it was a drop-in replacement for the original DebugView as a basic test. No additional features were really tested.

BUT, it did have less processing overhead than its precessor, especially while printing a lot verbose/information-level statements WITH the application running! There was not a noticeable application slow-down like before!

I'm looking to contribute here in the next couple of weeks. Been busy.

It's definitely better than it's precessor! Glad to see this repository is sponsored by JetBrains!

Keep up the good work!

janwilmans commented 7 years ago

SteeleDynamics: very interested in your contributions, what are you thinking of ?

harriv commented 7 years ago
  1. Yes, works mostly great :)
  2. Few feature request: #213 #109 (I'd like to have daily timestamp on filename, but it's minor detail:), #209 #135
PeterMortensen commented 7 years ago

For the console version, DebugViewConsole.exe, I got:

"DebugViewConsole 1.8.0.7 Neither output to logfile or console was specified, noting to do..."

  1. "noting to do" should be "nothing to do"

  2. I guessed I could use "-h" to list information about the command-line parameters. I suggest including information about "-h" in that fixed text output, e.g. like command "cp" on Unix, something like "Try `DebugViewConsole -h' for more information.".

harriv commented 7 years ago

@PeterMortensen I created #310 for first issue :)

PeterMortensen commented 7 years ago

On Windows XP 64-bit (really Windows Server 2008 in disguise) I get (I have closed the old DebugView, Visual Studio, etc.):

2017-10-17T16:36:01.35 T:\toDelete\2017-10-12\DebugViewPP\Debugview++ 1.8.07 - 32 bit version> DebugViewConsole.exe -c -p    

DebugViewConsole 1.8.0.7   

Listening for OutputDebugString messages...

Unexpected error occurred: CreateDBWinBufferMapping

Another DebugView++ (or similar application) might be running.

The same works on a Windows 7 64-bit system:

17-10-2017T16:22:01,60 C:\TEMP3\Debugview++ 1.8.07 - 32 bit version>  DebugViewConsole.exe -c -p

DebugViewConsole 1.8.0.7

Listening for OutputDebugString messages...

1440  16:22:09.472. Error frame group #9912 on CAN 1. CAN time:  1544.542142

1440  16:22:09.481. Error frame group #9986 on CAN 1_ALL. CAN time:  2364.603400

1440  16:22:11.502. Error frame group #9913 on CAN 1. CAN time:  1546.647072

1440  16:22:11.512. Error frame group #9987 on CAN 1_ALL. CAN time:  2366.708329

1440  16:22:13.530. Error frame group #9914 on CAN 1. CAN time:  1548.752027

Process ended normally.

I would like to try v1.5, but the download links are broken (near "Download old version (stable, dated 20 Sept 2015)", on page https://github.com/CobaltFusion/DebugViewPP).

Perhaps "Another DebugView++ (or similar application) might be running." should be augmented with this possibility (running on Windows XP or whatever it is that may prevent it from working on such a system)?

janwilmans commented 7 years ago

Its very likely related to the debug-rights granted to the account you are running in, you can try 'run as administrator' or similar things. Or granting debug right permanently to the account. The simplest way to do that is probably to add the user to the admin group, but there may also be subtler/more specific ways. Let me know if this helps.

PeterMortensen commented 7 years ago

So v. 1.8 is supposed to work on Windows Server 2008 / Windows XP 64-bit? I thought the last working version was v. 1.5 (or is that only for Windows XP 32-bit)? Or an SP2 vs. SP3 issue? I use SP2 (yes, I know it is out of date, but now it is probably too late to upgrade).

I am logged in as administrator on the Windows XP 64-bit system. I have used Visual Studio there for many years for developing .NET applications.

I have also tried to restart the computer, but it gave the same result.

I would like to try v. 1.5, but the download links are broken.

janwilmans commented 7 years ago

I am logged in as administrator on the Windows XP 64-bit system.

I have also tried to restart the computer, but it gave the same result.

I would like to try v. 1.5, but the download links are broken.

v1.8 should just work, although I do not guarantee anymore that future versions will keep working, I have not needed to break anything. I will put the links back soon.

janwilmans commented 7 years ago

It took some more time than I anticipated, but the v1.5 links at back up. Let me know what you find.

PeterMortensen commented 6 years ago

Sorry for the late response.

With the v. 1.5 of DebugViewConsole.exe (installed by the installer) I get the same result.

But two of the GUI versions work for capturing the debug output (but not for the programmatic access I am after), both v. 1.5 (32-bit) and v. 1.8.07 (32-bit), though the v. 1.5 version complains at startup with "Unable to capture Global Win32 Messages. Make sure you have appropriate permissions. You may need to start this application by right-clicking it and selecting 'Run As Administator' even if you have administrator rights.". They both do capture the debug output from my .NET application. (The 64-bit version, v. 1.8.07, does not start at all ("DebugView++.exe is not a valid Win32 application"), which is probably not surprising(?)).

Why would there be a difference between the command-line version and the GUI version? Aren't they more or less doing the same thing (shared code) for the initialisation part (handles \DBWIN_BUFFER, \DBWIN_BUFFER_READY, etc.)?

I have tried to fiddle with permissions, using RunAs, etc., but the results are inconclusive at this point. Stay tuned.

janwilmans commented 6 years ago

Try https://github.com/CobaltFusion/DebugViewPP/releases/download/1.8.0.7/DebugViewConsole.exe (not the one from the zip, this links is actual file, it might fix your issue, let me know if it does not...)

PeterMortensen commented 6 years ago

Sorry for the late reply.

It works!!! Thank you very much.

What did you change?

janwilmans commented 6 years ago

I was always trying to open to Global\DBWIN_BUFFER but on windows xp that is not a valid file-descriptor. However, the API method does not tell me that (it returns ok, even though it is not actually valid) Now I worked around that by detecting the windows version and not even trying to open it. see 2b4aae048237bea83df2ff0c28ea50ebc3de7e57

janwilmans commented 6 years ago

@harriv , about #213 #109, #209 #135, I would like them too, however, they are not trivial to implement in the current design. I'm considering a redesign/ new implementation, that is portable and allows me to implement these features also, see https://github.com/CobaltFusion/DebugVisualizer

ItsGeekman commented 6 years ago

Hello! Does the log window support the UTF-8 or UTF-16 encoding? When I use the C#'s Debug.WriteLine() method with "special" characters (like α, β, °, etc) the log window is unable to display it correctly (question mark is displayed instead).

janwilmans commented 6 years ago

Well, I have never used those symbols specifically, but I recently tested chinese Unicode chars and that works very well now. I would welcome a failing test.

techtim2003 commented 5 years ago

Feature request: Right-click filter option for "literal" process name and message. Basically a similar feature that procmon.exe or event log explorer has. It makes filtering out garbage much smoother.

janwilmans commented 5 years ago

@techtim2003 thanks for you suggestion, I'd like to make sure I understand correctly: you would like to filter by the full name of the process and the full message in one filter entry? I have spend a lot of time to make the filters understandable by humans :) and I'm having a hard time thinking what that would look like in the filter UI without creating a mess.

I simpler solution may to include the name of the process, or even the PID in the message, would that solve you case? (I personally always really disliked that about dbgview, but if its useful I could bring that back as an option?)

cpriest commented 5 years ago

Just wanted to drop a line and say thank you for the highly improved DebugView, I've used it in the past and now have need of it again and it's so much better.

RrnR commented 5 years ago

Congratulations on a fine product. I use it all the time. There is one thing that irks me (it's not the fault of DebugView++). I develop in Delphi. If I run a compiled app, my OutputDebugString lines go to DebugView++. All good. If I run my program from the IDE, the ODS output goes to the Delphi IDE Event Log, which has none of the filtering or highlighting abilities that DebugView++ has. AKAICT, there is no easy way or persuading Delphi to ignore ODS output and let it go to DebugView++ (well, there is - you can tell Delphi IDE to run the program without debugging - but if you do that, you lose the ability to set breakpoints, inspect variables and the call stack etc.).

I figure a way around this is to modify the app I am developing to spit the ODS output directly to DebugView++ - i.e. not call ODS, but instead call another routine that talks directly to a running instance of DebugView++.

What abilities does DebugView++ have that might help me to implement this?

janwilmans commented 5 years ago

That is actually quite easy to do, if you can write to stdout, you can just pipe that into debugview++. Alternately, you can send udp messages...

I can point you in the right direction, but I'm not at my desk right now, I'll respond asap

On Thu, Apr 25, 2019, 22:20 RrnR notifications@github.com wrote:

Congratulations on a fine product. I use it all the time. There is one thing that irks me (it's not the fault of DebugView++). I develop in Delphi. If I run a compiled app, my OutputDebugString lines go to DebugView++. All good. If I run my program from the IDE, the ODS output goes to the Delphi IDE Event Log, which has none of the filtering or highlighting abilities that DebugView++ has. AKAICT, there is no easy way or persuading Delphi to ignore ODS output and let it go to DebugView++ (well, there is - you can tell Delphi IDE to run the program without debugging - but if you do that, you lose the ability to set breakpoints, inspect variables and the call stack etc.).

I figure a way around this is to modify the app I am developing to spit the ODS output directly to DebugView++ - i.e. not call ODS, but instead call another routine that talks directly to a running instance of DebugView++.

What abilities does DebugView++ have that might help me to implement this?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/CobaltFusion/DebugViewPP/issues/283#issuecomment-486823315, or mute the thread https://github.com/notifications/unsubscribe-auth/ABNITBFEIV62XAGJUERNJOTPSIG7VANCNFSM4DT2BERA .

janwilmans commented 5 years ago

1) So the easiest way is this: image

2) another way is to use either TCP or UDP messages image

image

This will cause debugview++ to start listening for messages on the specified port. Here is an example of how to send UDP messages from your application (in c++):

https://github.com/CobaltFusion/DebugViewPP/blob/master/DbgMsgSrc/DbgMsgSrc.cpp#L277

I'm sure delphi has a component to do this as well.

RrnR commented 5 years ago

Cool, thanks for that. I'll investigate when I've put out the fire...

Actually, I don't see how the first example using pipes would work in my situation. So, I would be running my app in the Delphi IDE - would I continue to call ODS as normal? I can't see how that would work. If I added the ability in my app to call the UDP message instead of Win ODS, I can see how that would work, but I can't see how running my app under the IDE could be made to provide anything that could be piped - or are you suggesting that my app would spit stuff out to the console instead of calling ODS?

If I were to use UDP, presumably the instance of DebugView++ would only display those messages from my app - or would it also grab standard ODS calls from other applications as well?

markbearden commented 5 years ago

FYI: On current Windows 10, the last few executables archived here trigger my Windows Defender with a report of "Trojan:Win32/Tiggre!plock" (category Severe, so Defender insists on quarantine). Tried 1.8.0.46, 1.8.0.44, 1.8.0.33, 64 and 32 bit versions. If it could matter, this is on a VM installation of Windows 10.

https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?Name=Trojan:Win32/Tiggre!plock&ThreatID=-2147243670

I just downloaded the 1.8.0.46 source and successfully built the executable, and Windows Defender sees no threat in the 64-bit executable I built.

janwilmans commented 5 years ago

Thanks for reporting mark! I've seen similar reports, such as #353, and I have tried really hard to work around it, but it seems the just 'importing'/ linking to any debug function in the win32 api is considered dangerous now. So I'm not sure what to do about it. Glad you found that the x64 version seems unaffected!

janwilmans commented 5 years ago

@RrnR to get back to you: yes, I was suggesting that you write to the console from your app and re-direct that console to debugview++.. If that is unpractical, the UDP message solution might be preferable .

would it also grab standard ODS calls from other applications as well

yes, it would, but if that is annoying you, you can just filter those by process name.

RrnR commented 5 years ago

Thanks @Jan. I'll probably go the UDP way, I'm imagining it would be less impact. If I end up with something that's reusable and useful (Delphi) I'll post it.

janwilmans commented 5 years ago

Thanks, it would be great if you could provide a working Delphi example!

jan commented 5 years ago

@RrnR That's an excellent idea. Thanks for keeping me posted.

RrnR commented 5 years ago

@jan, sorry for the unintended nudge. I mean, what are the chances of two people named "Jan" on the web? ;-)

marknelson commented 5 years ago

I was pretty excited about the native ability to capture UDP messages. So far though, it looks like this isn't going to work for me. I have a couple of problems.

  1. I have a test app that sends 1,000 UDP messages a second, and I see many drops. I also see that when things get busy DebugView++ randomly inserts blank lines for no reason. Just for a datapoint, if I capture the UDP messages with my python relay and instead issue them with OutputDebugString(), no messages are lost. So Windows can keep up, my output is not a problem, DebugView++ just doesn't seem to be able to keep up with rapid traffic.

  2. I'd like to be able to disable OutputDebugString() traffic when using UDP, this doesn't seem possible, but it's also possible I have missed this in the docs.

janwilmans commented 5 years ago

Very cool, I would love to investigate this, can you send me your test app?

On Mon, Jun 17, 2019, 19:33 Mark Nelson notifications@github.com wrote:

I was pretty excited about the native ability to capture UDP messages. So far though, it looks like this isn't going to work for me. I have a couple of problems.

1.

I have a test app that sends 1,000 UDP messages a second, and I see many drops. I also see that when things get busy DebugView++ randomly inserts blank lines for no reason. Just for a datapoint, if I capture the UDP messages with my python relay and instead issue them with OutputDebugString(), no messages are lost. So Windows can keep up, my output is not a problem, DebugView++ just doesn't seem to be able to keep up with rapid traffic. 2.

I'd like to be able to disable OutputDebugString() traffic when using UDP, this doesn't seem possible, but it's also possible I have missed this in the docs.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/CobaltFusion/DebugViewPP/issues/283?email_source=notifications&email_token=ABNITBCLNWGQMUF2ZES7XC3P27DE3A5CNFSM4DT2BERKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODX34YXY#issuecomment-502778975, or mute the thread https://github.com/notifications/unsubscribe-auth/ABNITBFXURFBH7UZZKOEZPDP27DE3ANCNFSM4DT2BERA .

janwilmans commented 5 years ago

Oh btw to pause outputdebugstring traficx press the pause button, you'd expect it to stop receiving all messages, but thats actually a bug I forgot about, until just now ;)

On Mon, Jun 17, 2019, 19:33 Mark Nelson notifications@github.com wrote:

I was pretty excited about the native ability to capture UDP messages. So far though, it looks like this isn't going to work for me. I have a couple of problems.

1.

I have a test app that sends 1,000 UDP messages a second, and I see many drops. I also see that when things get busy DebugView++ randomly inserts blank lines for no reason. Just for a datapoint, if I capture the UDP messages with my python relay and instead issue them with OutputDebugString(), no messages are lost. So Windows can keep up, my output is not a problem, DebugView++ just doesn't seem to be able to keep up with rapid traffic. 2.

I'd like to be able to disable OutputDebugString() traffic when using UDP, this doesn't seem possible, but it's also possible I have missed this in the docs.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/CobaltFusion/DebugViewPP/issues/283?email_source=notifications&email_token=ABNITBCLNWGQMUF2ZES7XC3P27DE3A5CNFSM4DT2BERKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODX34YXY#issuecomment-502778975, or mute the thread https://github.com/notifications/unsubscribe-auth/ABNITBFXURFBH7UZZKOEZPDP27DE3ANCNFSM4DT2BERA .

marknelson commented 5 years ago

I need to extract the test app from our production code, will try to get that done tomorrow.

RrnR commented 5 years ago

Hi Mark,

I'd be interested in that test app as well, assuming I ever get around to writing a Delphi wrapper.

Best regards Ross

Ross McMillan

Home

+64 9 638-5225

Work

+64 9 415-2514

Mobile

+64 21 879-647

Email

rossmcm@gmail.com https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=ken@elecsyn.com

On Tue, Jun 18, 2019 at 7:48 AM Mark Nelson notifications@github.com wrote:

I need to extract the test app from our production code, will try to get that done tomorrow.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/CobaltFusion/DebugViewPP/issues/283?email_source=notifications&email_token=ADRRNAVYK43NIZRDWXYETTLP27TALA5CNFSM4DT2BERKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODX4IAEI#issuecomment-502824977, or mute the thread https://github.com/notifications/unsubscribe-auth/ADRRNATMMYY6L2B63TFO5C3P27TALANCNFSM4DT2BERA .

marknelson commented 5 years ago

Okay, I'm able to characterize the UDP problems pretty well - figuring it out proved interesting.

As it turns out, I was sending trace from a C++ program, and I was inadvertently including the null terminator in my UDP packet.

If you run this python script, sending 100K lines at full speed across the local network, DebugView++ reliably captures all packets.

However, if you uncomment the line that appends a null terminate, you'll see some crazy erratic behavior. It's almost like the lines are capture properly, but the rendering is going nuts.

Try this out, with and without the null terminator. This might work just as well if all the traffic is going through localhost, but I was going across the network:

from __future__ import print_function
import ctypes
import socket
import sys

sock = socket.socket(socket.AF_INET, # Internet
                     socket.SOCK_DGRAM) # UDP

for i in range(100000):
  msg = "Hello, world {0}, testing 012345678901234567890123456789".format(i)
  #msg = msg + chr(0)
  sock.sendto(msg, ("10.57.42.250", 9000))
#
janwilmans commented 5 years ago

wow, that is super helpful! I think I'll be able to fix that :) I'll investigate it !

RrnR commented 5 years ago

Hi Jan,

I have the bones of this going, but I would like to start DebugView++ from the command line with the listener at 127.0.0.1:2020 enabled, as it doesn't seem to remember the setting between invocations.

Is there a command line option, or any other way to do this?

One other suggestion:

When I load an XML file with filter specifications, and one of those specifications has a malformed regex, I get an untrapped exception (regex_error(error escape) FilterDlg.cpp:124) and the filter spec is not loaded. Would it be possible to handle the exception (still display a snag message) and leave that spec disabled?. At least the filter would load and show the dud filter specs.

Best regards Ross

janwilmans commented 5 years ago

I tried to fix the loading of filter rules with broken regular expressions, but that is not easy. Its XML, I either load the whole thing, or not. The new edge cases that will arise from loading broken regex's and still continueing are not fun to deal with. How do you get into this situation in the first place? Debugview++ shouldn't allow you to save that file, so did you edit it manually ?

RrnR commented 5 years ago

No, I haven't been editing directly the XML file. I had a quick look and can't see the text that is causing it to barf. I might be a bit more structured about it and try to isolate the filter concerned.

One point is that the folder where the XML files are located is within my Dropbox synced image, so I can have access to my filters both at home and at work, but I've never known Dropbox to damage a file.

I don't understand why the exception is occurring within the LoadXML routine? I would have thought the regexp at that stage is just treated as a string by the XML loader, and you would parse it with the regexp parser after the XML had been loaded.

Finally (!) did you see my request about avoiding the need to add the UDP address and port each time I start DebugView++?

RrnR commented 5 years ago

OK more information. I've isolated the expression it doesn't like:

<Text>Error\:\ </Text>
<MatchType>Regex</MatchType>
<FilterType>Token</FilterType>

The curious thing is that I don't remember recently editing this filter and I'm sure it worked previously. The specific error is:

image

A bit of playing about (by directly editing the XML and then reloading the filters) has determined:

<Text>Error\:\ </Text>    fails (both colon and space escaped)
<Text>Error:\ </Text>     fails (only space escaped)
<Text>Error\: </Text>     loads ok (only colon escaped)
<Text>Error: </Text>      loads OK (neither escaped)

There is definitely something amiss. If I edit the XML so that there are no escaped characters in the regex (fourth line above), the filters load OK and the colon and space are both respected. It looks like neither colon or spaces need to be escaped. However, I can escape them (it's my experience that if you escape a character that doesn't need escaping, the regex just ignores the escaping). If I edit the filter in the dialog so that it reads: "Error\:\ " (ignore the quotes - they are just there to make it plain there is a trailing space) then the regex is correctly interpreted and the output lines are rendered as I would expect. If I save the filters and inspect the XML, the text is stored in exactly the same way as I entered it in the filters dialog - i.e. <Text>Error\:\ </Text>. If I try to load the filter by XML filename I get the exception.

The following will hopefully make it clearer. It doesn't behave as I would have expected.

Case 1

Case 2

This curious because I would have expected the code that loads the XML would be the same in both cases, yet only one case gives the exception. I'm thinking maybe a Unicode-type problem but I really don't know.

DV++ Version: 1.8.0.46

RrnR commented 5 years ago

Hi Jan, Any progress on these issues?

Many thanks, R

janwilmans commented 5 years ago

I worked on it, the loading problem ugly, likely a wont fix, although there might be a save bug to fix so you never get it that situation in the first place.

I'll add a cmdline option to add sources, although, you might be able to use debugviewcmd to achieve the same and them monitor the file with the ui version

On Thu, Sep 19, 2019, 03:51 RrnR notifications@github.com wrote:

Hi Jan, Any progress on these issues?

  • the exception loading a filter with a trailing save in the regex, as described in my previous post.
  • the ability to specify the UDB host and port on the DBV++ command line.

Many thanks, R

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/CobaltFusion/DebugViewPP/issues/283?email_source=notifications&email_token=ABNITBAU5UPOYLNS72LEKUDQKNDTJA5CNFSM4DT2BERKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7C4Z4I#issuecomment-533056753, or mute the thread https://github.com/notifications/unsubscribe-auth/ABNITBFM4PERQTB46IMY7E3QKNDTJANCNFSM4DT2BERA .

janwilmans commented 5 years ago

Btw at cppcon now so expect a delay

On Thu, Sep 19, 2019, 10:30 Jan Wilmans janwilmans@gmail.com wrote:

I worked on it, the loading problem ugly, likely a wont fix, although there might be a save bug to fix so you never get it that situation in the first place.

I'll add a cmdline option to add sources, although, you might be able to use debugviewcmd to achieve the same and them monitor the file with the ui version

On Thu, Sep 19, 2019, 03:51 RrnR notifications@github.com wrote:

Hi Jan, Any progress on these issues?

  • the exception loading a filter with a trailing save in the regex, as described in my previous post.
  • the ability to specify the UDB host and port on the DBV++ command line.

Many thanks, R

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/CobaltFusion/DebugViewPP/issues/283?email_source=notifications&email_token=ABNITBAU5UPOYLNS72LEKUDQKNDTJA5CNFSM4DT2BERKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7C4Z4I#issuecomment-533056753, or mute the thread https://github.com/notifications/unsubscribe-auth/ABNITBFM4PERQTB46IMY7E3QKNDTJANCNFSM4DT2BERA .

RrnR commented 5 years ago

No problem.

Thanks. R

On Fri, 20 Sep 2019, 4:31 AM Jan Wilmans, notifications@github.com wrote:

Btw at cppcon now so expect a delay

On Thu, Sep 19, 2019, 10:30 Jan Wilmans janwilmans@gmail.com wrote:

I worked on it, the loading problem ugly, likely a wont fix, although there might be a save bug to fix so you never get it that situation in the first place.

I'll add a cmdline option to add sources, although, you might be able to use debugviewcmd to achieve the same and them monitor the file with the ui version

On Thu, Sep 19, 2019, 03:51 RrnR notifications@github.com wrote:

Hi Jan, Any progress on these issues?

  • the exception loading a filter with a trailing save in the regex, as described in my previous post.
  • the ability to specify the UDB host and port on the DBV++ command line.

Many thanks, R

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub < https://github.com/CobaltFusion/DebugViewPP/issues/283?email_source=notifications&email_token=ABNITBAU5UPOYLNS72LEKUDQKNDTJA5CNFSM4DT2BERKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7C4Z4I#issuecomment-533056753 , or mute the thread < https://github.com/notifications/unsubscribe-auth/ABNITBFM4PERQTB46IMY7E3QKNDTJANCNFSM4DT2BERA

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/CobaltFusion/DebugViewPP/issues/283?email_source=notifications&email_token=ADRRNARYUWVJBX7ZICWF2GDQKOSPHA5CNFSM4DT2BERKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7ECI4I#issuecomment-533210225, or mute the thread https://github.com/notifications/unsubscribe-auth/ADRRNAQ55ZXHNBYDJ5BUGPDQKOSPHANCNFSM4DT2BERA .

IcetipsAlta commented 4 years ago

Hi,

Been using DebugView and then DebugView++ for a long time. In recent builds the "clear log" hotkey was changed from Ctrl-X to Ctrl-Shift-X. Is there any way to make this combination configurable?

Thank you for excellent software!

Joliciel commented 4 years ago

Hi,

DebugView is a very useful tool, I’m using it daily, I really like it and very easy to use. I have even created an object class to handle the statements and the indentation on the screen in order to have a better formatted view of the code. I see the beginning the end easily of a procedure sentence, with the colour it talks to you, it even helps you to get ideas. Every section areas are colorized differently with beginning and end stacking as I mention with an indentation it really helps to narrow down a bug or logic that needs to be improved or solve. I’ve been using it daily in my programming for the past 15 years. Every time I program the window it is there waiting to receive messages from the program. It is stable. The DebugView sessions of a process vary from a few hundreds lines to around 450,000 lines.

I’ll like to know if there’s a way to save with the DebugView file the bookmarks we are making, if it does, how is it done? A suggestion about the find bar, it would be nice to have an history of our search taken from our prior past sessions. The issue that I’ve encountered there is one, it is usually on a DebugView session of more than 100,000 lines, after using a forward search and when we select the previous button for an above search the DebugView crash.

Thank you for the excellent software !

RrnR commented 4 years ago

Me also, I use it frequently. After some pointers from Jan, I now use it to debug programs running under the Delphi IDE. Normally, when running a program from the IDE, calls to OutputDebugString go to the Delphi Debug window. This slows program execution considerably, and the debug window is also plagued by spurious ODS calls from Windows and other apps with rogue ODS calls that developers didn't bother to remove. I now send my ODS messages via UDP calls to DebugView++. I can use output colour-coding and filtering, and execution speed isn't slowed down nearly as much. Another major advantage is that you can use the Delphi IDE breakpoints, single-stepping and variable watches, with your technicolour nd watchAnd the same thing works with no changes when I am running the executable stand-alone.

The main hassle is that DBV doesn't remember the UDP settings between invocations, so I have written a batch file wrapper that invokes DBV and then stuffs the keystrokes necessary to set up the UDP input. It works, but it's a bit ugly, and not always reliable.

What would be really cool is a command-line option to enable the UDP and set the address and port.

... Please?

Best regards Ross

Ross McMillan

Home

+64 9 638-5225

Work

+64 9 415-2514

Mobile

+64 21 879-647

Email

rossmcm@gmail.com https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=ken@elecsyn.com

On Fri, Jan 24, 2020 at 6:00 PM Joliciel notifications@github.com wrote:

Hi,

DebugView is a very useful tool, I’m using it daily, I really like it and very easy to use. I have even created an object class to handle the statements and the indentation on the screen in order to have a better formatted view of the code. I see the beginning the end easily of a procedure sentence, with the colour it talks to you, it even helps you to get ideas. Every section areas are colorized differently with beginning and end stacking as I mention with an indentation it really helps to narrow down a bug or logic that needs to be improved or solve. I’ve been using it daily in my programming for the past 15 years. Every time I program the window it is there waiting to receive messages from the program. It is stable. The DebugView sessions of a process vary from a few hundreds lines to around 450,000 lines.

I’ll like to know if there’s a way to save with the DebugView file the bookmarks we are making, if it does, how is it done? A suggestion about the find bar, it would be nice to have an history of our search taken from our prior past sessions. The issue that I’ve encountered there is one, it is usually on a DebugView session of more than 100,000 lines, after using a forward search and when we select the previous button for an above search the DebugView crash.

Thank you for the excellent software !

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/CobaltFusion/DebugViewPP/issues/283?email_source=notifications&email_token=ADRRNAS7E6DZCN4Q4JBOI6TQ7JYXVA5CNFSM4DT2BERKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJZXKBQ#issuecomment-577991942, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADRRNARPC3CEAM3PJIFYUS3Q7JYXVANCNFSM4DT2BERA .