Debugging Tricks : Going Blank
in [Visual Basic]
|
Prev: Redirection
Next: Correct Way To Wait
From: Webbiz on 4 Mar 2010 17:47 On Thu, 4 Mar 2010 07:19:30 -0500, "David" <NoWhere(a)earthlink.net> wrote: >I use this at the beginning and end of all my procedures > > #If kDEBUGON Then > Debug.Print "----------------------------------------" > Debug.Print "Begin ToolDragBegin" > #End If > >kDEBUGON placed in: > >Project / Properties / Make / Conditional Compile Arguments > >If kDEBUGON = 0 then it is ignored. >If kDEBUGON = 1 then it is executed. > >============== > >Note this will generate a lot of debug statements > > > >"Nobody" <nobody(a)nobody.com> wrote in message >news:uRNEdf4uKHA.5036(a)TK2MSFTNGP02.phx.gbl... >> "Webbiz" <nospam(a)noway.com> wrote in message >> news:8spuo5p4clr3vlk62lk0vjah5a29mfp1cc(a)4ax.com... >>> >>>>Just curious, how can a Sub/Function be called more times than >>>>necessary?? >>>> >>>>I always think the other way around, if the same code is needed in more >>>>than >>>>one place, make it a Sub/Function. >>>> >>>>/Henning >>>> >>> >>> >>> I had a break set in my DrawChart routine the other day and ran the >>> program. This routine draws a chart on a picturebox. >>> >>> When I continued the program from that single break point, it returned >>> to that break point again. >>> >>> I realized, at that point, that I need to make sure my procedures are >>> not being called unnecessarily. Why do I need to draw the same chart >>> twice? >>> >>> The DrawChart is called from MANY locations within the program. It is >>> called when the user scrolls. It is called when the user changes the >>> time frame. It is called when the user draws on the chart. It is >>> called when the user deletes something from the chart. Etc. Etc. >> >> Try adding a CallerID parameter at the end. Example: >> >> Public Sub DrawChart(..., Optional ByVal CallerID As Long) >> Debug.Print "DrawChart: called, CallerID = " & CallerID >> ... >> End Sub >> >> > Conditional Compile Arguments Hmm. Never gave that box much thought. Will have to find documentation on how it is used. Thanks. Webbiz
From: Webbiz on 4 Mar 2010 17:50 On Thu, 4 Mar 2010 06:51:14 -0600, "Larry Serflaten" <serflaten(a)usinternet.com> wrote: > >"Webbiz" <nospam(a)noway.com> wrote > >> Meanwhile, I'm thinking that it would be great if I could generate a >> list that shows the order in which the procedures are called from the >> point I start the program until the point it stops initializing >> (drawing the chart, etc.) and sits there waiting for someone to click >> something. >> >> It appears from the comments that this can't be done? > >You should know better than that! > >Load your project, and press F8. Then get your pen and paper and >write down the routines as they are called. Keep pressing F8 until >pressing F8 does nothing. It is at that point that your program is >waiting for user input. > >LFS > What??? Manual labor? Are you nutz??? Why do you think I want to program stuff? To automate everything. Pressing F8 over and over again and writing stuff would give me finger cramps. Heaven forbid I develop finger abs from this. :-b You'd think that is something can press F8 a bunch of times and print each function/sub that starts and ends would have been created by now. Where are the super code freaks that can do this kind of power coding? And thus ends another episode of LOST. :-) Webbiz
From: Webbiz on 4 Mar 2010 17:53 On Thu, 04 Mar 2010 09:53:03 +0000, Dee Earley <dee.earley(a)icode.co.uk> wrote: >On 03/03/2010 20:14, Webbiz wrote: >> Over the last months/years, I've been shown some simple approaches to >> debugging here for which I'm grateful. > >Further to the other answers, this page explains some other general >debugging concepts: >http://hashvb.earlsoft.co.uk/Debugging Thanks Dee. In the 19 years I've been using VB (yep, since 1991 when I switched from Delphi), not only am I still a novice but I have NEVER, EVER used the # debugging code stuff nor found the time to learn about it. Life just goes by way too fast. Guess now I'd better get to it. :-) Webbiz
From: Karl E. Peterson on 4 Mar 2010 17:57 Webbiz wrote: > In the 19 years I've been using VB (yep, since 1991 when I switched > from Delphi), not only am I still a novice but I have NEVER, EVER used > the # debugging code stuff nor found the time to learn about it. Wow, well, there was one period where I found conditional compilation invaluable -- the transition from 16 to 32bits. I could write code that'd drop into either environment. Very nice. Haven't had a lot of use for it otherwise, though. Good to know about. -- ..NET: It's About Trust! http://vfred.mvps.org
From: Webbiz on 5 Mar 2010 00:11
On Thu, 04 Mar 2010 14:57:16 -0800, Karl E. Peterson <karl(a)exmvps.org> wrote: >Webbiz wrote: >> In the 19 years I've been using VB (yep, since 1991 when I switched >> from Delphi), not only am I still a novice but I have NEVER, EVER used >> the # debugging code stuff nor found the time to learn about it. > >Wow, well, there was one period where I found conditional compilation >invaluable -- the transition from 16 to 32bits. I could write code >that'd drop into either environment. Very nice. Haven't had a lot of >use for it otherwise, though. Good to know about. Why do you say that you "haven't had a lot of use for it otherwise..."? I'm not doing any 'transistions' from 16 to 32. So why then would it be good to know? I'm asking because I know you're a VB PRO, and if a 'pro' doesn't find much use for it, I have to wonder if my time is best spent otherwise? Thanks. Webbiz |