Page 1 of 2
debug issue
Posted: Mon Apr 04, 2011 8:30 am
by BruceN
I have a logical variable (public) that is somehow changing value when it shouldn't. I have a break point at every place the variable can change value (thru VX20 2.0.338). I still can't tell when its changing. Thre's a
watch list' in VX, but I cant get variables into it.. and the variable view (view, debug window, variables) is always blank also. Under tools, debugger options I have all variabletypes clicked to show, but my Variable screen is different from thati n the help file (mine doesn't have the 'manipulation' section on it).
How can I get the variable values to display in the degug window to track their values? How can I get one or 2 into the watch window?
I tried using Roger's WTF... but that only shows the value AT THAT POINT. Is there a method in Express of watching the value as it chnges when I step thru the code?
as always.. thanks
Re: debug issue
Posted: Mon Apr 04, 2011 9:11 am
by Tom
Hi, Bruce.
Move all accesses/assignments to the var(s) to a get/set-function which sets the value or returns it. Place your debug code there (use DC_CallStack). Do you work with XPF-files and "RESTORE FROM" / "SAVE TO"? Maybe you restore the value there.
Re: debug issue
Posted: Mon Apr 04, 2011 10:03 am
by rdonnay
Tom -
That's what I was going to suggest, but I didn't know how many publics would be affected by this.
I'm working on updating a client application, written by another programmer, in which he used a large public array and accessed each value through a function named Publics(). At first, this was cumbersome code to look at but I find that it is much easier to debug because every public is Get or Set through this function.
I tend to use very few publics in my apps, so I don't usually need something like this, but it's a good programming idea.
Roger
Re: debug issue
Posted: Mon Apr 04, 2011 12:35 pm
by Auge_Ohr
this "Technique" is used by "Summer 93"*** to get rid of PUBLIC Variabel.
(*** there was realy a Product with this Name )
Code: Select all
FUNCTION SP_Duration(nValue)
IF PCOUNT() > 0
nDuration := nValue
ENDIF
RETURN (nDuration)
you can put all Function into one PRG and use #xtranslate with a "big" Array
Code: Select all
#xtranslate nDuration => Stack\[SP, 1]
...
#xtranslate cHelloWorld => Stack\[SP, 100]
STATIC Stack := {}
STATIC SP := 0
FUNCTION _STACKINIT()
AADD(Stack,ARRAY(100))
SP ++
RETURN (SP)
FUNCTION _STACKEXIT(nThread)
LOCAL iMax
ADEL(Stack,nThread)
DO WHILE .T.
iMax := LEN(Stack)
IF iMax = 0
EXIT
ELSEIF Stack[iMax] = NIL
ASIZE(Stack,LEN(Stack) - 1)
ELSE
EXIT
ENDIF
ENDDO
SP := LEN(Stack)
RETURN (SP)
you can use same "Technique in a Class ( STATIC -> Class VAR ) when have multiple MDI-Client Windows , each have its own "Stack".
Re: debug issue
Posted: Mon Apr 04, 2011 12:39 pm
by rdonnay
Jimmy -
I have used that technique many times in the past too, but it doesn't solve the problem of triggering a debug event when writing to the variable.
Roger
Re: debug issue
Posted: Mon Apr 04, 2011 1:03 pm
by Auge_Ohr
hi,
Code: Select all
nDuration := 100
FindExpression ( {|| nDuration = 0} )
FUNCTION FindExpression (bBlock)
oThread := Thread():new()
oThread:start("Sp_StopHere",bBlock)
oThread:setInterval(100)
RETURN
FUNCTION Sp_StopHere(bBlock)
IF EVAL(bBlock)
? PROCENAME(2)
? PROCLINE(2)
WAIT
ENDIF
RETURN
Re: debug issue
Posted: Mon Apr 04, 2011 1:13 pm
by BruceN
thanks guys.. question: what's the problem with public variables?
Re: debug issue
Posted: Mon Apr 04, 2011 1:25 pm
by Tom
what's the problem with public variables?
Advantages:
1. PUBLICs are visible everywhere, even in different threads.
2. PUBLICs can be initialized in a function, they get visible "above".
3. PUBLICs can be stored to/restored from a XPF-file (as PRIVATEs).
4. PUBLICs can be changed everywhere, changed values are visible instantly - everywhere.
Disadvantages:
Same as above.
If you run the same code in two threads and change a public var in one, it's changed for the other thread aswell. This may happen just in the midth of code which started with a different value of the var. Imagine a var switching an option. Now code runs for this option while this option is changed. Your app may crash. The results of the code may be wrong. Or, or, or.
Re: debug issue
Posted: Mon Apr 04, 2011 1:28 pm
by Auge_Ohr
BruceN wrote:question: what's the problem with public variables?
i do not think Xbase++ have "spezial" Problem with it. ( see what Tom say )
Cl*pper DGROUP is limited to 64Kb ( not MB ) which PUBLIC use, so when you Application growe you might got into Trouble with DGROUP.
Re: debug issue
Posted: Mon Apr 04, 2011 2:09 pm
by Cliff Wiernik
I utilize a small number of public variables to house configuration parameters that are loaded at program startup and not changed by programs. It was due to the visability desire as the program was created originally in summer87 this way. I could use a get/set function also for the same purpose but never went fully that way.
So I don't have problems with things being inadvertently changed.