5

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

5