How to find an error in a form 6

[german12]

I have VFP-form with many command buttons on it.
When I run the form and click a button in form, I get an error message.
So I try to find the error by doing "modif form myform" and then I can press the button in question and look at the code behind where the error could be.
That would be logical for me - but it is not like that.

what I don't understand:

After clicking the button, the code for the button that I clicked does not appear, but a code for a button that I had previously called appears - and it does not have to be the same button - so I have to call up a list of all buttons on the form - and then I have to go through the list again to find the right button, behind which the faulty code should be.

My question:
Is this a wrong setting in my system - a weakness of VFP - or can I look for errors in a completely different and better way if a form has many button objects?
What is the quickest/most efficent way to look for such errors?

Thanks for advice

Klaus



Peace worldwide - it starts here...

 

[Nigel Gomm]

Klaus,

trying to guess what is going on - a screenshot might help.

when you double click the button (in the modify form window)....VFP will show you just one event's code.

it could be you just need to look at the combobox at the top and select "click" to see the click event's code.
e.g.

then to track down the error.... either step through the code with the debugger or surround everything in the click event with try... catch.

e.g.

try
..existing code
.
.
.
catch to loerr
messagebox(loerr.message+"@"+transform(loerr.lineno)+" in "+loerr.procedure)
endtry

hth

n

 

[TamarGranor]

When you double-click any control on a form, the method code window opens. It should be showing a method of that control, but what method it shows depends on which (if any) methods of that control contain code. If there's code in multiple methods of the control, VFP has some rule I've never figured out for deciding which one to show first on a double-click.

If you want to go directly to a specific method, click on the control and then in the Property Sheet, double-click on that method.

To further confuse the matter, what is shown in the method code window is the code that was added directly in the form. So, if the button is based on a class and the Click code is actually in the class, not the button on the form, when you open the Click method in the form, you won't see any code. In that case, click the View Parent Code button at the top of the method code window and then choose the class whose version of that code you want to see. You can't edit it there, but you can see it.

Beyond all that, it's easier to debug using the Debugger than just reading code. There's too much to tell you about how to do that in a single message. (Check out my paper at

http://tomorrowssolutionsllc.com/Co... the Visual FoxPro Debugger Effectively.pdf.)

But to get started, choose Suspend when the error occurs and, if it doesn't open automatically, open the Debugger.

Tamar

 

[Chris Miller]

I couldn't explain it better than Tamar. Regarding "the rule" of which method is shown, I didn't observe it in detail, but I think somewhere in an SCX or thePJX VFP stores what method you edited last.

So getting to the click event code isn't a standard, it's just most often the case you program into the click event.

No idea why you would get the click event of something else, but that might be code of a container into which a button is nested, ie you clicked on the container, not on the button within. At runtime there is a "click through" behaviour, both container click and button click events occur, the container click usually does nothing. But at design time the nesting of controls in containers (literally the container control but also pageframes, grid columns and anything acting as a container) are addressed before the controls nested inside them. If you CTRL+Click on a container you activate the containers inside in the designer and it is highlighted with a cyan border. Only then clicks on a button in that area are opening methods/events of it and not the higher level container.

Before VFP had the "View Parent Code" we had Ken Lebvy's Super Cls tool, and it enabled editing the superclass (=parent class), too:

https://fox.wikis.com/wc.dll?Wiki~SuperCls

Chriss

 

[Mike Lewis]

I can't add much to the good advice you have been given, Klaus, except to say that, rather than looking at the code when you "modi form", you should use the Debugger whenever possible.

When you run your app in the development environment and you get an error, you will normally see an error message with options to Cancel, Suspend and Ignore. Choose Suspend. This will then open the Debugger, with the Trace window showing the method that caused the error. Not only will you see the actual code that the button (or whatever) is executing; you will also be able to see the values of all the variables in scope, and loads of other information as well.

If, when the error occurs, you see an error message but without the Cancel, Suspend and Ignore options, that's probably because you have your own error-handler in force. This is the code that is specified in the ON ERROR command. When testing your program in the development environment, it's best not to use an error-handler, that it, not to execute the ON ERROR. This is how you can achieve that:

IF (VERSION(2)=0)
	ON ERROR DO ErrorRoutine WITH ERROR(), MESSAGE(), PROGRAM(), LINENO()
ENDIF

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[german12]

Everything ok - thanks for the many hints - the solution was very simple for me:
As you can see in the photo below, I have always - to see the code - first clicked the RIGHT mouse button to mark the button - and then I clicked on "Code" in the submenu with the LEFT mouse button.

This leads to the fact that you see a code that you have previously viewed, but not the actual code that is behind the command button.

I didn't even think about the double-click - it's the fastest way to get to the code behind the button.
Sometimes it's the simplest things that you can't think of - I just hope it doesn't just happen to me ...
Anyway, everyone's answers here are all useful.
There are many ways to achieve your goal - this obviously not only applies to VFP.
The biggest mistake is only when you don't dare to ask something here.
Or - as we say: There are no stupid questions, only stupid answers.

Thanks again to all of you.

Gruß aus Deutschland
Klaus





Peace worldwide - it starts here...

 

[Steve Meyerson]

Hi German,

To second what's already been said, the native VFP debugger has saved an enormous amount of time for me.

You may already know all of my narrative below, but I'll put it out there anyway for 'newguy' benefit.

Specifically, I type SET STEP ON just before the point of code I'm concerned about. The debugger appears at that point. I click on an icon at the top to step thru each line of code. At any step, I hover over variable names or property names to instantly show their values.

If one of them I'm concerned about is not shown, I type it into the Watch textbox to display its value. It might also be in the Locals list, but often it's not shown because it requires scrolling to see.

When a value changes in either list, it is displayed in red.

I'm not a debugger expert, but there are numerous other capabilities in the debugger which can best be learned just by 'playing' with it.

HTH

Steve

 

[german12]

Thank you very much Steve - and you are right


- the beginner may shy away from using the debugger - there are so many new things to learn (and remember) that using the debugger is not a high priority in the beginning.
Many textbooks also only cover the debugger superficially.

Klaus


Peace worldwide - it starts here...

 

[Steve Meyerson]

p.s. I forgot to mention my favorite feature - the ability to view the entire contents of an array. Just thought I'd mention it.
Steve

 

[TamarGranor]

FWIW,I'm not a big fan of putting SET STEP ON in code. I do it only in situations where I can't find another way to stop at the right place.

Most commonly, I ever set a breakpoint in the IDE before running the code or I use the Watch window to set a breakpoint against an expression like "MYMETHOD"$PROG().

The advantage here is that I don't have to remember to go back and remove SET STEP ON once I solve the problem. You can remove breakpoints in a bunch of ways that don't require changing code.

Tamar

 

[Steve Meyerson]

Tamar,
Point well taken. I'm just an old guy ignoring "new tricks". But your suggestion is certainly a worthwhile endeavor for me.

Steve