	   Midwest Fox Pros, Inc. Newsletter for September 1994
			    (CompuServe Edition)

Fox Bytes
 Volume 3 Number 8                                        September 1994

Official Newsletter of the Midwest Fox Pros User Group
		      

		   From the Editor

Interest in the Screen Builder presentations made by 
Carolyn Patterson and Kelly Conway was quite evident by 
the big turnout we had for last month's meeting.  
Attendance the last two months is up, which is a good 
sign that the we are addressing more of the needs of the 
members.  Those present asked many good questions, 
which led to greater understanding of the capability of the 
Screen Builder.  As one becomes familiar with the 
capabilities we begin to add more enhancements to our 
screens.  Because of the interest shown two additional 
presentations will be made at the October meeting - 
integrated browse and multiple screen sets.

How would you like a workshop that features tracks on 
FoxPro (both 2.x and fundamentals, and preparing for 
FoxPro 3.0), Access and Visual Basic, that is aimed at 
technical computer personnel at corporations, technical 
personnel at computer consulting compaines, independent 
consultants, programmers and developers?  That is exactly 
what the Milwaukee Association of FoxPro Developers, 
the publisher of DevNotes..., is hosting November 11 and 
12.  It is being sponsored by Microsoft.  The cost is $125 
if registered by Sep 17, $150 by Nov 6, or $175 after Nov 
6.  Could we put on such a workshop?  You bet we could!  
A lot will depend on the interest shown.  If you would like 
to attend such a workshop let your Executive Board know, 
either by a note in the suggestion box, or a note on the 
BBS.  We may even have a sign-up sheet at the door on 
which you can put your name if this type of an event 
appeals to you.   

 

     September 13,  Meeting Agenda 

      Johnson County Community College, Room CEC 211

6:30 - 7:00  Registration and Checkin.
All members and visitors must check in.  New 
memberships and renewals will be taken at this time.  
Members should bring their membership cards to speed up 
entry to the meeting.
			      Page 1 of 10
6:30 - 7:00  User's Forum
Users of FoxPro have the opportunity to ask the experts 
questions of a non-developmental nature.  The focus in on 
new and novice users.

7:00  -  9:00  Presentation - George Goley will 
provide interesting insites into FoxPro Performance Tips.

9:00  -  9:10  Break

9:10 - 10:00  Developers Exchange Session.
Discussion of advanced issues and topics related to FoxPro 
and database management.



 The Midwest Fox Pros

Executive Staff  
 President ..................Kelly Conway      - 525-8601
 Vice-President .............Brett Duvall      - 792-4896
 Secretary ..................Carolyn Patterson - 492-7071
 Treasurer ..................Brad Young        - 454-4441 
 
Committee Chairs

BBS .........................Brett Duvall      - 792-4896
Events  .....................Andy Carey        - 833-2406
Membership  .................Del Bethke        - 422-7774
Technical Resources..........Chris Caviness    - 252-4617
Newsletter ..................Don Remen         - 436-9246


Membership Information
  
Our membership now stands at 103.  Memberships are 
$36.00 annually.  Corporate memberships are also 
available.  Members of the Midwest FoxPros receive Fox 
Bytes, our monthly newsletter, as well as access to our 
Bulletin Board System (BBS).  


		From the President

Good afternoon, baseball fans! You have one less reason 
to miss the September user group meeting because "I had 
tickets to the Royals' game" will not be an acceptable 
excuse this month. Good thing too, because you're not 
going to want to miss this month's meeting.

George Goley will be in town, teaching a week long class 
for intermediate-level FoxPro developers. Once again, we 
were lucky enough to talk George into speaking to our 
user group while he's in town. The topic of George's 
presentation this month will be FoxPro Performance Tips.  
Several of us have seen George's performance sessions 
before. Be sure to bring a good pen and plenty of paper so 
you can take notes as George probably will break the one-
tip-per-minute barrier. Who knows, he may even 
		       Page 3 of 10
(accidentally, of course) mention a few things about 
FoxPro V3.00!

On another front, we received quite a few forms from 
people who would like to take advantage of the new 
mentoring program. Thanks to those of you who already 
have submitted your forms and hang in there - one of our 
mentors will be contacting you soon. We'll take forms 
from anyone else at the next meeting or you could just call 
me at 816/525-8601 and let me know of your interest.  
Also, please contact me if you are interested in being a 
mentor. We have three at the moment and always could 
use more.

Lastly, for those of you who voiced an interest in a 
developer's contest, I just want to mention that nothing 
that I know of is being done about that at this time. If 
there still is an interest in this great idea, you may want to 
volunteer to get the ball rolling (I don't have the time, 
personally).

Kelly

. 

OOPS!  WE GOOFED

Sorry gang, we're only human!  We sincerely apologize to 
everyone who tried to use the source code listing for 
"Calculating the Number of Workdays" in the August 1994 
issue of Fox Bytes, written by Tom Bellmer of Sprint.

     The source code below corrects the error and omission 
(changes are noted in bold face type).  The problem has to 
do with the ending date's DOW() value being less than 
the beginning dates DOW() value.  If this situation is true, 
then a weekend has occurred that was formerly not 
accounted for.  The corrected source code listing is as 
follows:

FUNCTION u_wrkday
  *-- Written 07/14/94 by Thomas D. Bellmer,
 Sprint 816/854-7750
  *-- Revised 08/17/94 to account for ending
  *  DOW() < beginning DOW()
  PARAMETERS ldbegdate, ldenddate
  PRIVATE ldbegdate, ldenddate, lnnumdays, + ;
  lnretvalue, lnselarea, lnholidays
 ldbegdate   = ldbegdate + VAL(SUBSTR("1000002", + ;
  DOW(ldbegdate),1))
  ldenddate   = ldenddate - VAL(SUBSTR("2000001",+ ;
  DOW(ldenddate),1))
  lnnumdays = ldenddate - ldbegdate
		   Page 4 of 10
lnretvalue   = lnnumdays - (INT(lnnumdays / 7) * 2)
  IF DOW(ldenddate) < DOW(ldbegdate)
	lnretvalue = lnretvalue - 2
  ENDIF
  lnselarea    = SELECT()
  IF NOT USED('holidays')
	USE holidays IN 0
  ENDIF
  SELECT holidays
  COUNT FOR BETWEEN(holiday,ldbegdate, +;  
  ldenddate) TO lnholidays
  SELECT(lnselarea)
  lnretvalue   = lnretvalue - lnholidays
  RETURN(lnretvalue)


Note:  The lines of code with the "+" sign and the ";" are 
meant to show the continuation of the line of code.  When 
you create this program be sure that you type the 
instructions containing continuation code on the following 
line all on one line and leave out the "+" and ";" in the 
code.


DATA FILE CORRUPTION
(worst nightmare... or just an inconvenience?)
J. Brett Duvall, United Consulting Corp.

In time, all of us working with FoxPro will come across a 
trashed database.  Generally, this is caused by abnormal 
FoxPro termination, whether from power failure or the 
user resetting the PC.  It can also, however, occur as a 
result of hardware (hard disk) failure or improper copying 
of files in DOS (you need to keep the .DBF and .FPT files 
together).

Some database problems may require the ultimate fix 
(Restore from a backup), but many may be resolved with 
some ingenuity or an external program.  I'll limit my 
discussion here to a couple of the more common problems 
which FoxPro will report when you try to open the table:

- Error #15- Not a Table/DBF file
This is by far the most common database corruption.  
When FoxPro appends a record to the file, it first attaches 
the right number of bytes to the file, populates those bytes 
(with blanks if you APPEND BLANK) and then updates 
the file header to indicate the new record count.  If the 
power is cut off in the middle, there may be problems such 
as a record count inconsistency or no EOF marker.  
Although sometimes you may be able to use the APPEND 
FROM command to put the data into a clean file, it is 

			     Page 5 of 10
often easier to fix the file with a database utility program.  
As it turns out, there are two on the Fox Bits BBS 
(FIXDBF.ZIP and DBRX.ZIP).  Both have instructions 
included and I think I'll leave their specifics for an 
upcoming demonstration.  If you are interested, please call 
me or leave a message on the BBS.

- Error #41- Memo file is missing/invalid.
Normally, this means you copied some files in DOS and 
forgot to copy the FPT files with them.  There are 
programs on the market which can salvage this 
information also.  I am told dSalvage can do it.  If you 
don't care about the memo data:
1. rename the bad .cdx  (in DOS)
2. create a dummy file with a memo field (no records)
3. rename the dummy's .FPT to match what the bad .cdx 
used to be.

Many times, the file can be fixed without losing data.  
However, your best defense against data loss is to keep 
current backups of all your program and data files.

Applications Used:
FoxPro 2.6 & manuals
FixDBF.Exe (from BBS)
DBRX.Exe (from BBS)

Ext. References: 
Mike Droste, US Central
Kelly Conway, Practical Business Solutions

WANT ADS

Advertising in Fox Bytes can benefit your business.  We 
reach an audience that is very specific, allowing you to 
costeffectively target your market.  The standard ad is 3.5" 
x 4.5" in size.  Please call  Kelly Conway, or Don Remen 
for listings.

	  Rates:          Members:   $2.50 per month

		       Non-members:  $10.00 per month

We are also more than happy to place buy or sell, help-
wanted, or situation-wanted ads at no cost to our 
members.


				Page 6 of 10
BULLETIN BOARD NEWS

BBS dial-up (816) 525-3692
    If problems are encountered in accessing the system, 
contact Brett Duvall (816) 792-4896.
     Initial modem settings to access the BBS are 2400/
4800 N 8 1, with the handshake set to Xon/Xoff.

Information Line
      To keep abreast of the latest schedule changes, call the 
Information Line (816) 525-4050.


   Tips & Tricks for Faster Applications

TIP #1 - When using list boxes, explicitly 
initialize the variable beforehand.
     If your list box is a field list from a database with even 
a couple thousand fields, your screen can take literally 
seconds to draw.  It can take just as long to redraw when 
you issue a SHOW GETS.

     The reason is that FoxPro will default your variable as 
a single space " ".  If there is no empty field in your list, 
FoxPro will search through the entire list looking for a 
match before returning use of the screen to your user.

     If you initialize the list box variable beforehand to one 
of the first entries on the list, FoxPro will find it right 
away, preventing the delay.  Better yet, initialize it to a 
number.  Then FoxPro can position the selection bar on 
the list and doesn't have to search at all.
TIP #2 - Hide slow screen draws.
     Although this is more of a problem in Windows, it can 
be a problem in FoxPro DOS also.  If the user can watch 
the individual objects on a window being drawn, they will 
get the impression that your application is slow.  The best 
solution is to hide your screen while it is being drawn, 
then "instantly" pop your fully drawn window into view.

     The easiest ways to do this is to position your window 
off the screen in the screen builder.  Go into Screen 
Layout, uncheck the "Center" check box, and enter a 
position off the screen.  In Windows, a vertical position of 
-1000 should do the trick.  In DOS, a vertical position of 
100 should be fine.

     To make the window visible to the user, add the 
MOVE command in the READ WHEN clause (snippet) as 
follows:
	     MOVE WINDOW mywin CENTER
				or
	     MOVE WINDOW mywin TO 2,2
			Page 7 of  10
TIP #3 - Slower can be faster.
     Well,... it can seem that way.  When you have some 
processing to do that takes more that a few seconds, users 
often mistakenly think that the computer has locked up.  
Be sure to provide your user with some indication that the 
computer is still at work.

A status bar is a nice way to let the user know that 
something is still going on and even gives them some idea 
how much longer they will have to wait.  An alternative 
to this could be a window with a "checklist".  A list of 
tasks or items that need to be processed and is updated 
each time one item is completed and another is started.

     Regardless of the method you use to show progress, it 
will likely slow down your application a small amount.  
But the user will still get the impression that processing is 
faster.  They will also be less likely to reboot.  Both of 
these results are good for you.

TIP #4 - Build a timing table.
     This tip has some ties with tip #3.  If you have any 
processing tasks that take a long time to do (such as 
reindexing a large number of files), it is a nice habit to let 
the user know how long it might take.

     A message saying something like "Reindexing will 
require exclusive use of the databases for about 30 
seconds.  Do you want to continue?" might be appreciated 
by your users.  Unfortunately, the reindex that took 30 
seconds during development on your 486, might take 30 
minutes on the users' 386sx now that there are 100 times 
as many records.

     The solution is to keep a table of tasks like this.  One 
that tracks how long it took to run the last time.  Then as 
the databases grow, or if the users' computer is slower 
than yours, your application "learns" the new times.

     If your application is going to be run on a network, it 
might not be a bad idea to keep track of times by the task 
AND the computer being used.  That way the person with 
the 16 MHz 386sx computer on the "old" network cabling 
doesn't get times based on the power user who has a 100 
MHz Pentium on the fastest cabling in the building.

TIP #5 - Be aware of PRIVATE declarations.
     Like the next tip, this one isn't a very obvious time 
eater.  Declaring variables that are going to be used in a 
function/procedure as PRIVATE will make it run faster.  
But beware, using PRIVATE ALL LIKE <skeleton> will 
slow it down instead.  But, note -- George Goley 
recommends that usage.
		      Page 8 of  10
TIP #6 - Use  SET DELETED ON.
     The more deleted records your database has in it at any 
one time, the more this will speed up your application.  
But for it to give you a speed benefit, you will need to 
create an index tag for deleted records.  This will allow it 
to take advantage of the Rushmore technology.  This is 
accomplished by using INDEX ON DELETED() TAG 
deleted.

(The TIPS in this article originally appeared in the 
July 1994 edition of "DevNotes...", the newsletter 
of the Milwaukee Association of FoxPro 
Developers.)

Multi Screen Development and Linkage

Summary
The following steps will show how to create several 
screens, and upon execution of the code, allow the transfer 
of focus between the vavrious screens.  This is useful 
when you need to go from screen to screen in a linear 
fashion.

Additional Details:

Create a screen doing the following steps:
   1)  Select File, Screen, New   <OK>
   2)  From the Screen heading select,  Screen layout
   3)  Select the "Window" radio button and give it a name 
	of "MAIN"., and title it "Main Screen".
   4)  Under the "Type" choice, enable the "Float" option.
   5)  Make the size Height: 10, Width: 40 and position the 
	row & column at 0 and 0 respectively.
  6)  Under the "Screen" menu choice, choose "Push 
	Button".  For the prompt, enter "Go to Screen 2".
   7)  For the "Variable" field, enter BUTTON1.
   8)  Under the "Valid" clause, enter the line _CUROBJ =
	OBJNUM(BUTTON2)
  9)  Position the button somewhere in the middle of the 
	screen.
  10)  Choose File, and Save As, "SCREEN1"

Repeat the steps above for the 2nd screen, with the 
following changes:

   3)  Give it a name of  NOTMAIN.
   4)  Title it "Second Screen"
  5)  Position this screen at coordinates 9,35 so there is 
	some overlap.
   6)  For the prompt, enter "Go to Main Screen"
   
   7)  For the "Variable" field, enter BUTTON2. 

		       Page 9 of 10
8)  Under the "Valid" clause for the button, enter the line 
	_CUROBJ = OBJNUM(BUTTON1)
10)  Choose File, and Save As, "SCREEN2".

Now, click on or select the Main Screen and make it the 
active screen.  Choose Program, Generate.  Select "NO" to 
"Save environment information".  In the box for the 
"Screen Code" the output file should be  
"<drive>:\path\SCREEN1.SPR".  Choose "Generate".

After the code has been generated, close the screens by 
clicking on the upperleft-hand corner of the screen box.  
In the command window, issue the command "Do 
SCREEN1.SPR".  You should now be able to click on the 
buttons and transfer focus to the respective screens.

(NOTE:  Our thanks to Jim Wilson for providing this 
helpful information.)


       FUTURE EVENTS

FoxPros User Group meetings are subject to change 
without notice, please contact the FoxPros Information 
Line for current information.  FoxPros Information line is 
(816) 525-4050

1994 Schedule

    Date                   Location              When

   Oct 11               JCCC Room             6:30 PM
			   CEC 211
 
    Topic:     Follow on Screen Builder - Integrated            
	Browse and Multiple Screen Sets

   
     Nov 8                JCCC Room             6:30 PM
			      CEC 211

     Topic:    Introduction to Report Writer
		   Advanced Report Writer tips

	  
      Dec  13            JCCC Room               6:30 PM
			      CEC 211
      Topic:   SQL Select techniques
