Posted 17 years ago on 12/29/2007 and updated 6/12/2008
Take Away: Techniques for thinking about where to put code in Paradox's object-based event model.
KB100769
One of the hardest aspects for beginning ObjectPAL programmers is deciding is deciding where to place code. Novice ObjectPAL programmers tend to place code everywhere. Rather than work with the default behavior, the event model, and the data model, beginners often tend to put code in the wrong place. Later, they add more code to try to fix an inelegant approach.
Programmers who use DOS PAL and traditional procedural languages are used to writing a lot of code. In the Windows version of Paradox, they tend to over code to get the results they want. Understanding the system can make the difference between inelegant and elegant code.
Taking the time to understand the default behavior of objects, the event model, and the data model can save you much time. If you don't fully understand how an object works, you could end up working harder and accomplishing less. Much of this book deals with this issue.
About Coding
When new users to Paradox begin writing code in ObjectPAL, they often write tremendous amounts of code. The amount of code can become overwhelming if you don't understand the fundamentals of the product.
Usually you follow certain steps whenever you develop an application. Before writing a single line of ObjectPAL code, you always should build the data model and arrange the form until it's similar to what you want. Then, run the form and work with it to see what it does and doesn't do. When you find something that you want to work differently, ask yourself, "What do I want to happen?" and "When do I want it to happen?" Try to do this for only one task or object at a time. In other words, develop in small steps.
Go back and forth between Design mode and Run mode and test your work incrementally. When you're done coding and testing a single object, move to the next. By refining your application in steps, you end up with functioning code in bite-sized chunks. If you try to tackle in one step all the work that an application requires, you can easily end up frustrated, with messy code. Remember, program and test one task at a time.
Watch Out for Spaghetti Code
BASIC, early Pascal, and early C promoted spaghetti codeintertwined code with many repeated parts. These procedural languages required you to write line after line of code. Although modern languages don't lend themselves to spaghetti code, it's still possible to write it. During the development process, you might copy a routine from one spot to another and later find a bug in it. You would have two pieces of code to correct. This is fine if you are perfect and can remember to change both pieces of code. But this method of programming is hard on upkeep, and it makes reusing code nearly impossible. You would have to start every new project from scratch.
Try to Localize Code
Because you're programming in ObjectPAL (an object-based programming language), the code should be as local to the object as possible. For example, if you're trying to decide to put code on a button or the form, then choose the button. If the situation warrants moving up to the form level, it will become obvious. There are many benefits for coding as low as possible, including the ability to copy objects with code on them from one form to another and still have it work. Whenever you have a choice, try adding ObjectPAL code directly to the object to get the desired results. Do you ever want to not code locally? Yeswhen you want to work with more than one of the same object. You can use a container above all the objects and put code on the object's container.
Code as Low as Possible
Put code on the lowest possible container. If you later need to use the same code elsewhere, move the code up the container path to the lowest container that both objects can see. If you follow this rule, your code will be compartmentalized and portable. By developing in compartments, you keep code segments apart. A bug introduced in one compartment is less likely to affect other parts of your application.
If you are programming a button, put all the code, including variables, on the button. This makes the button a self-contained unit that is easily copied and pasted to other forms. If you later need that same code on another button, convert it to a custom method and move it up the container path to the button's container object. A container object is an object that completely surrounds and controls the behavior of all the objects within it.
If you then decide you need to use the code with several pages within the form, then move the custom method to the form. If you need the same routine in several forms, consider putting it in a library. A library is an object that stores custom ObjectPAL code. Libraries are useful for storing and maintaining frequently used routines, and for sharing custom methods and variables among forms.
Using this general rule of coding as low to the object as possible gives you maximum access to your code and saves you time. In addition, if you later find a problem with the routine, you need to correct it in only one spot; instantly, all code that uses the routine benefits from the improvement.
Although you can write spaghetti code with an object-based language, ObjectPAL supports and promotes good object-oriented practices. By using contained objects and custom methods properly, you can keep your code clean. Develop in self-contained units whose code is protected from other objects.
Paradox
Print This
