Skip to main content

Posts

Showing posts from July, 2007

Alerting Users in your FoxPro Application

Every application needs a way of notifying users about something. The first "something" that may come to mind is an error, which unfortunately, needs a very special kind of alert or handler. But there are lots of other events that users need to be aware of, whether you as the developer plan for them or not. In January 2007 issue of FoxPro Advisor, Mike Lewis wrote about a forced system shutdown "event" that would let administrators get all users out of the system. If you are running a process that may take a while, you might need to let users know when it has been completed. If you have a large application, there could be many events that require user notification. Perhaps worse, there may be many events that your users could have reacted to, "if only they had known" before something was happening. Some applications rely on reports to display this information – but why waste paper when you can simply alert users to an event?

Refactoring in Visual FoxPro

(this article was written prior to the Code Analyst but identifies the origins of where this tool came from)
With the sheer number of functions, commands and tools available within Visual FoxPro, it's easy to find more than one way to do the job.

So multiply the number of ways by the number of developers on your team, and it's pretty easy to see why code maintenance is pretty important.

Refactoring is about making code more useable (not changing the functionality but making it easy to understand and maintain).

This article presents 3 core concepts:
1 - Never Use Keywords for variable or field names
2 - Use the most recent functions where appropriate
3 - Encapsulate, encapsulate, encapsulate