|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Using OutputDebugString too much can cause slowness in GUI responseFYI, I have been having problems with a ListView with about 100 items, and
when I try to scroll vertically or horizontally by dragging the scroll bar, it doesn't catch up immediately, but it looks highlighted and frozen, and catches up later. It turned out the reason for it was that I was using OutputDebugString too much, printing the text for each item and sumitem(There are 8 columns in this list view), and DebugView was open to view the output. When I close DebugView, the problem is gone. I was using OutputDebugString at a rate of 1000/Second. The items also appeared to flicker more frequently, I am not sure if it's related. Just a FYI, in case someone else is having this problem. I've seen you mention this function before.
I just looked up both, but I don't get it. What's the advantage/reason for using OutputDebugString rather than Debug.Print? Likewise, what's the advantage of DebugView over the Immediate window? Show quoteHide quote | FYI, I have been having problems with a ListView with about 100 items, and | when I try to scroll vertically or horizontally by dragging the scroll bar, | it doesn't catch up immediately, but it looks highlighted and frozen, and | catches up later. | | It turned out the reason for it was that I was using OutputDebugString too | much, printing the text for each item and sumitem(There are 8 columns in | this list view), and DebugView was open to view the output. When I close | DebugView, the problem is gone. I was using OutputDebugString at a rate of | 1000/Second. | | The items also appeared to flicker more frequently, I am not sure if it's | related. | | Just a FYI, in case someone else is having this problem. | | On Sat, 21 Aug 2010 08:31:57 -0400, "Mayayana"
<mayayana@invalid.nospam> wrote: > I've seen you mention this function before. Because the Immediate Window is only available when a component or>I just looked up both, but I don't get it. >What's the advantage/reason for using >OutputDebugString rather than Debug.Print? >Likewise, what's the advantage of DebugView >over the Immediate window? > program is run within the VB IDE, therefore you can only instrument non-native compiled (pcode) debug releases, and only on boxes where VB is installed. Other minor advantages are: 1) Debug viewers usually have larger buffers 2) You can view the output of more than one component in one place which is not only convenient but can provide a better view of concurrences. -ralph Mayayana wrote:
> I've seen you mention this function before. The obvious one is that they work with compiled code, not just in the> I just looked up both, but I don't get it. > What's the advantage/reason for using > OutputDebugString rather than Debug.Print? > Likewise, what's the advantage of DebugView > over the Immediate window? IDE. "Mayayana" <mayayana@invalid.nospam> wrote in message If you have subclassing code that crashes the IDE when you stop it, then you news:i4ogsj$njl$1@news.eternal-september.org... > I've seen you mention this function before. > I just looked up both, but I don't get it. > What's the advantage/reason for using > OutputDebugString rather than Debug.Print? > Likewise, what's the advantage of DebugView > over the Immediate window? have to compile it, but Debug.Print output won't show up. Note that when Debug.Print is compiled into an EXE, the call is not removed, but the result is discarded. If you have a statement like: Debug.Print "LicenseKeyVerify: UserName = " & UserName Then anyone can view your EXE with a Hex editor, or trace where the call is in the disassembly, and break the licensing scheme if it's shareware. However, Debug.Assert is removed from the EXE, so don't add code that take action like a function call. You can test this be compiling the following: Option Explicit Private Sub Form_Load() Debug.Print MsgBox("Hello from Debug.Print") Debug.Assert vbOK = MsgBox("Hello from Debug.Assert vbOK") Debug.Assert vbYes = MsgBox("Hello from Debug.Assert vbYes") End Sub When I run this in the IDE using VB6, I get all three MsgBoxes, but the IDE breaks at the last Debug.Assert because the result is False. When I run this in an EXE, I only see the first MsgBox.
Show quote
Hide quote
On Sat, 21 Aug 2010 10:43:28 -0400, "Nobody" <nob***@nobody.com> Well, might as well add DebugBreak to the pile.wrote: >"Mayayana" <mayayana@invalid.nospam> wrote in message >news:i4ogsj$njl$1@news.eternal-september.org... >> I've seen you mention this function before. >> I just looked up both, but I don't get it. >> What's the advantage/reason for using >> OutputDebugString rather than Debug.Print? >> Likewise, what's the advantage of DebugView >> over the Immediate window? > >If you have subclassing code that crashes the IDE when you stop it, then you >have to compile it, but Debug.Print output won't show up. > >Note that when Debug.Print is compiled into an EXE, the call is not removed, >but the result is discarded. If you have a statement like: > >Debug.Print "LicenseKeyVerify: UserName = " & UserName > >Then anyone can view your EXE with a Hex editor, or trace where the call is >in the disassembly, and break the licensing scheme if it's shareware. > >However, Debug.Assert is removed from the EXE, so don't add code that take >action like a function call. You can test this be compiling the following: > >Option Explicit > >Private Sub Form_Load() > Debug.Print MsgBox("Hello from Debug.Print") > Debug.Assert vbOK = MsgBox("Hello from Debug.Assert vbOK") > Debug.Assert vbYes = MsgBox("Hello from Debug.Assert vbYes") >End Sub > >When I run this in the IDE using VB6, I get all three MsgBoxes, but the IDE >breaks at the last Debug.Assert because the result is False. When I run this >in an EXE, I only see the first MsgBox. > Private Declare Sub DebugBreak Lib "kernel32" Alias "DebugBreak" () This replaces VBs "Debug.Assert False" to trigger an outside debugger. On 20/08/2010 15:29, Nobody wrote:
> FYI, I have been having problems with a ListView with about 100 items, and Yeah, the calls are serialised and block on each other and the listeners.> when I try to scroll vertically or horizontally by dragging the scroll bar, > it doesn't catch up immediately, but it looks highlighted and frozen, and > catches up later. > > It turned out the reason for it was that I was using OutputDebugString too > much, printing the text for each item and sumitem(There are 8 columns in > this list view), and DebugView was open to view the output. When I close > DebugView, the problem is gone. I was using OutputDebugString at a rate of > 1000/Second. Note that even without a listener, they still block on each other which will cause problems if used from multiple threads/processes. -- Dee Earley (dee.ear***@icode.co.uk) i-Catcher Development Team iCode Systems (Replies direct to my email address will be ignored. Please reply to the group.) |
|||||||||||||||||||||||