Click HERE
to order online
Downloads
Subscription info here.
|
Click HERE
to order online.
Authors:
Rainer Becker,
Jim Booth,
Tamar E. Granor,
Doug Hennig,
Rick Schummer,
Eric Selje
Length: 24 pages (A4)
Formats Available: Printed (incl. electronic) or Electronic only
Printed format: A4 (210x297 mm or 8.3x11.7 in)
Electronic format: PDF
Single Issue Price ($US): 29.00 (printed+electronic) $19.00 (electronic only)
Press date: July, 2009
Printed issue availability: 2009/07 issue being mailed on 8/09.
Electronic issue availability: Available for download.
Source code: Available for download.
July, 2009 - Number 9
Editorial: All You Can Eat!
[[Rainer Becker]]
It's conference time again.
VFPX: PEM-Editor
[[Rick Schummer]]
Rick covers the Tabbing Navigation project this month in his continuing series of articles on the open source project known as VFPX hosted on CodePlex. This project provides developers with a snappy dialog filled with the titles of the open windows as well as a list of standard Visual FoxPro windows available for selection. This enhancement to the Visual FoxPro Interactive Development Environment (IDE) is clean and a fast way to find a specific instance of an editor or designer window when you have numerous instances open.
Custom UI Controls: Splitter
[[Doug Hennig]]
Adding a splitter control to your forms gives them a more professional behavior and allows your users to decide the relative sizes of resizable controls.
New Ways: Use the Toolbox!
[[Tamar Granor, PhD]]
Until now, I’ve focused this column on the FoxPro language, covering commands and functions. In this issue, I want to take a look at one of my favorite recent tools, the Toolbox, introduced in VFP 8.
Best Practices: Best Practices Part V
[[Jim Booth]]
Last time we discussed some of the concepts that allow us to really exploit our object oriented approach to system development. This time we will pull back a bit and look at our work from a more distant perspective. We will look at the very big picture of our system design by focusing on the architectural structure of our systems.
Test Driven Development, After the Fact
[[Eric Selje]]
Test-Driven Development (TDD) is easiest when you do it right from the start. But once you’ve written a lot of code it may seem overwhelming to start testing it after the fact. But if you change any of that existing code, having tests is the best way to ensure that you don’t break any functionality. It may seem like a catch-22, but it is worthwhile to create tests on legacy code so you can use to make sure that doesn’t happen.
|
|
