The LA Fox Developer Newsletter

December 1997

Newsletter Feedback...

Greenbar Revisited

by Russell Campbell, Atlanta FUG

[Ed. Note: The LA Developer gets circulated pretty far afield

sometimes. This response, to the "greenbar technique”

published in the last newsletter, is from Russell Campbell of the

Atlanta FoxPro Users Group.]

Got your LA Fox Developer Newsletter. Looks good! Did notice

one pet peeve in it.. . page 6, right column.. . programmer

wants to simulate green bar paper. I turned the page before

getting any farther - I was just skimming. Then I thought ‘Well,

I’d do that with a “print when” that checks a variable that

switches from true to false on each line. So I turned back to

see what solution was given. Very similar, but why a function?

A report variable (PrintIt) that inits to true then the “value to

store” is simply Not Printlt. Easier, in my mind, but this is not

really the pet peeve. The function...

if x = .t.

x = .f.

return .t.

else

x = .t.

return .t.

endif

can be simplified to

x = not x

return

or even

return not x

I maintain a system by a guy who loved to return a true or false

from a function - no problem there - it was just how he did it.

return lIf(a > b, .t., .f.)

instead of

return a> b

A lot of programmers don.t seem to understand me simple

boolean stuff. I also have seen a number of programmers who

use more complex logic when a line like...

a=b=c

will do.

Like I said.. . one of my pet peeves. I suppose I’m guilty of

making simple things too difficult at times <g>.

Thanks for sending the newsletter!

Russell

Visual Time & Effort’

By Mike Merino Rocky Mountain Fox User Group

PROBLEM:

Place a field on a parent form that is a running total of a numeric

field in a related child table. (and demonstate the relationship

between a text box, it’s new property and new method)

INTRODUCTION:

At Denver Public Health, employees are sometimes paid from

more than one funding source. The task was to build a Visual

Fox project to track employee funding sources using references

to two related FOXPRO 2.5 tables, a parent table <

g:\apps\admin\position.dbf> and a child table

<g:\apps\admin\tmeeff1. .dbf>. The linking fields are

position.posnum and timeeffi .posnumb, which contain the

employee’s position number. Because the parent table is

manipulated in Foxpro 2.5, in Visual Foxpro it is considered a

“free” table to eliminate problems between the two versions of

Foxpro.

The main Time & Effort form has a SEARCH button that calls a

second form: SEARCH. The SEARCH form was developed for a

previous project and so to incorporate into this project, was just

copied into the same subdirectory and the form called from the

SEARCH button.

This project was especially interesting in that it showed me the

reasons for and how to use NEW PROPERTIES and NEW

METHODS. Thanks to the RMFUG Lab group for their help in

sorting some of this out.

1. Set up of form

1.

I first created a new blank form and named it “Time and

Effort”.

(Con’t, page 6)

Page 5