posted 10-22-2006 10:46 PM         

It is not only for newbie users, but even for you experienced EZGUI users.

Some of this is based on my own personal programming experience, but also from a lot of experience from helping my customers.

First, let me say that in dealing with all the tech support for a number of years, I have found a common thread:

In 9 out of 10 cases, the EZGUI user has made a simple oversight in their code and the problem is not in the EZGUI engine

This does not mean that EZGUI never has any bugs, it has, it does and will likely do so in the future (thats the nature of software, nothing is truly 100% bug free).

It is just that often I find that a user may think something is seriously wrong in how EZGUI does something, they panic and they get frustrated thinking no solution may be found.

The first rule to good programming is:

(1) Slow down, relax, be patient

Often things are not as serious as they may seem. Often the problem is a simple code error or some problematic code in an event it should not be in.

The next rule is:

(2) Be methodic and meticulous in searching for the problem

Often a user, expects me to find the source of the problem (yet it likely is an error in their own code) in minutes after bringing the problem to my attention.

In the end, in frustration the user may send me some sample code to work with and then I begin to debug it.

How do I find the problem, they obviously are overlooking ?

By my being meticulous and methodic !

Next rule:
Use the proper debugging techniques for an event based programming environment

In being meticulous and methodic you need to know how to do this.

First, every EZGUI user should be using the EZGUI Debug Form (EZ_DebugForm and EZ_DPrint commands) for debugging. I put it in EZGUI for a reason.

It is one of the best debugging tools, available for debugging an event based application

If you are not using the debug window, then you are not debugging properly.

Don't depend upon a compiler debugger !
Don't depend upon an external debugger !
There is no such thing as a smart debugger program.

You the programmer, are the best debugger

The debug window is a simple mechanism so you the debugger, can track things as they happen in real time by printing them out to a window.

You should be asking questions, like "did the event even fire as expected ?"

Did the event occur when I expected it to ?

Did the event occur in the order I expected (before or after another event) ?

You also need to be testing for the values of variables (or event parameters, like CVal&) by using EZ_DPrint to see if they are what you expect.

Use a pencil and paper

This may sound old-fashioned, but learn to use a pencil and paper!

If you were to look at my desk at this very moment, you would see "lots" of papers with lots of scribbles on them. Often they are notes about some API I should research or some problem I an working on or they are noted of tests I have run trying to solve a problem.

In this age of computers, programmers have become lazy in they want the computer to do all the work. They want to computer to solve all the problems. They want to computer to do most of the work in writing software.

I am suggesting that it is high time programmers start using their best asset and that is themselves.

A programmer with no paper on his desk is likely not using his own brain power to the full. Learn to draw flow charts or diagrams of the problem at hand. Write notes about tests you have done and the conclusions you have come to. When using the debug window in EZGUI, write down data that may useful in solving your problem.

Read your own code!

This may sound silly, but it is crucial to solving problems. Learn to take the time to literally go through your code and read it one line at a time carefully examining it for flaws. This may take time, but do it!

Learn to test your program carefully so you can estimate where the problem may lie (what section of code is worth examining) and then take the time to read that code carefully.

I find it useful sometimes to print that code out on paper, so I can ponder it away from my computer. I can then write notes on it and draw lines on it to indicate code flow.

Do not assume the worse!

Often when something doesn't work the way we expect, the tendency is to assume the worse, like "oh, EZGUI is totally broken" or "my app is totally unstable now".

Often the reality is that the problem is because of a very simple oversight or a very simple error in handling an event.

To illustrate:

An EZGUI app GPF's and the user thinks that everything is broken and something is seriously wrong. When examined more closely, it turns out the user called the EZ_SetText command for a text control, within its %EZ_Change event. By changing the text one generates a new %EZ_Change event, so by doing this in a current %EZ_Change event, one can easily create an infinite loop. A we all know that inifinite loops often produce a GPF sooner or later.

My point is that, it is best to assume that one has simply made a small error in coding, even if the results seem disastrous (like a GPF).

To find the source of the problem is going to require, time and patience, plus also good debugging skills, since it will seem like one is trying to find a "needle in a haystack". This is why I strongly suggest that one use the EZGUI debug window.

By simply putting code like this in the PreProcess_Events routine:

code:

IF FormName$<>"DEBUG1" THEN
    EZ_DPrint FormName$+" "+STR$(CID&)+" "+STR$(CMsg&)+" "+STR$(CVal&)
END IF

One can display all the events in the order they occur in the dbeug window. You can modify the code above to test for specific events or a specific form to narrow down the search.

By doing this one would quickly have seen that the infinite loop was generating hundreds of %EZ_Change events. You would know that the %EZ_Change event for a specific event was suspect and then you could examine the code more closely looking for your error.

Stay tuned for part 2 ...