---------------------------------------------------------------------------- ---------------------------------------------------------------------------- NNNNNNNNNNNN NNNNNNNNNNNN NNNNNNN NNNNNN NNNNNNN NNNNNN NNNNNNNNNNNNNN NNNNNNNNNNNNNN NNNNNNNN NNNNNN NNNNNNNN NNNNNN NNNNNN NNNNN NNNNNNNNNN NNNNNNNNN NNNNNN NNNNNNNNN NNNNNN NNNNNN NNNNN NNNNNNNN NNNNNNNNN NNNNNNN NNNNNNNNNN NNNNNN NNNNNNNNNNNN NNNNNN NNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNN NNNNNN NNNNNN NNNNNNN NNNNNN NNNNNNNNNN NNNNNN NNNNNNNNNN NNNNNN NNNNNN NNNNNNNN NNNNNN NNNNNNNN NNNNNN NNNNNNNN NNNNNNNNNNNNNN NNNNNNNNNNNNN NNNNNN NNNNNNN NNNNNN NNNNNNN NNNNNNNNNNNN NNNNNNNNNNN NNNNNN NNNNNN NNNNNN NNNNNN ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- Boston Computer News Network January 1995 A Service of the Boston Computer Society, USA Vol.1, No.8 Sponsored by the Foxpro SIG Foxpro Version ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- Table of Contents ------------------------------------------------------------------------ 1. Introduction 2. BCS FoxPro Meetings 3. BCS Fox User Group at Networks Expo Boston '95 4. BCNN/Fox At FoxPro DevCon 5. Paul Maskens - Commenting on Psych Profile of compatibility with OOP 6. Harold Chattaway - Software Metrics 7. Ed Hartel - Closing Foxpro for Windows - NOT! 8. View your Diary -- The Sequel 9. Running External Tasks in Windows 10. SHIFTing Interface 11. BCNN Statement of Ownership, Copyright, and Responsibility ---------------------------------------------------------------------------- 1. Introduction ------------------------------------------------------------------------ ReplyTo: David Rose [73164,2263] DevCon is almost here, and we'll be there! Check us out as we bring you special editions of the BCNN Foxpro Newsletter - straight from our reporters at DevCon. If any of you happen to be attending, please submit your insights, thoughts, criticisms and exuberances. We are sure to see big changes in the Foxpro development environment, with a new name and that "OO" word. If it seems a little frightening, just remember - you are the consumer of this product. Don't let OO buzzwords intimidate you into complacency. Instead act like you would checking out the features on a new computer or automobile. As always, the good questions are: * Does this work for me? * Is this feature something that will make my work easier or better? * What new opportunities will this open up for me? * What are the costs, especially the hidden ones, that I incur with this new technology? Don't get me wrong, I think that object oriented is great, especially when it comes to GUI programming. I think that we will discover Visual Foxpro 3.0 will help Foxpro developers make another quantum leap in productivity. But I haven't seen the product yet, and you can bet that I will be asking some hard questions. 2. BCS FoxPro Meetings ------------------------------------------------------------------------ ReplyTo: Arnold Bilansky [71533,1031] (617)522-3700 x374 Meeting: Wed., Jan. 25, 1995, 7:00pm (Main meeting night moved) Place: Microsoft Office, 9 Hillside Avenue, Waltham, MA USA. Ted Roche, "A DevCon Wrapup" including our first local glimpse of VFP3. Meeting: Thurs., Feb. 2 1995, 6:30pm-7:30pm Place: Aquinas College, Jackson Rd., Newton, Waltham, MA USA. David T. Anderson, VFP3 For The Non-FP Programmer 3. BCS Fox User Group at Networks Expo Boston '95 ------------------------------------------------------------------------ ReplyTo: Arnold Bilansky [71533,1031] (617)522-3700 x374 On Wed. Feb. 15, The BCS FoxPro User Group presents three free Visual FoxPro 3.0 (VFP3) technical sessions at Networks Expo Boston '95. Location: Hynes Convention Center, 900 Boylston Street, Boston. 1:30pm FoxPro Advisor Contributing Editor Drew Speedie [Prosoft} "VFP3 Object-Oriented Programming Techniques" 3:30pm Microsoft MVP award winner Y. Alan Griver [Flash] "VFP3 Client/Server Connectivity Enhancements" 5:30pm Microsoft's lead programmer on VFP3 Morris Sim "VFP New Features: A Developer's Prospective" In addition to our free BCS FoxPro sessions (and other BCS presentations, all requiring no fee or preregistration), for admission to the massive vendor exposition or information on the Networks Expo seminars (fee required) call Bruno-Blenheim at (800) 829-3976. 4. BCNN/Fox At FoxPro DevCon ------------------------------------------------------------------------ ReplyTo: Arnold Bilansky [71533,1031] (617)522-3700 x374 Join the BCNN team as DevCon reporters. Editors Ted Roche and I will be roving around on-site gathering hot news, tips, and humor. We will hot-wire copy back to David Rose for special BCNN/Fox DevCon editions. If you have not registered for DevCon, you should know that all attendees paying the regular fee will go home with a beta copy of VFP3. To register, call (800) MFOXPRO in the US; 612 593-0677 internationally. 5. Paul Maskens - Commenting on Psych Profile of compatibility with OOP ------------------------------------------------------------------------ Reply To: Paul Maskens [100012,3274] The following raises several interesting points; valid to FOXPRO, ACCESS and VB developers alike as we move into the brave new buzzword of OOP. [Editor's note: and the brave new world of Visual Foxpro.] I've marked my own questions and comments [thus] ----- From Computing, 1/12/94 ----- NatWest assesses object skills with "lie detector" ================================================== The National Westminster Bank is using a computer-based psychological profiling tool to find which IT staff will be able to develop object- oriented applications. [Is psychological profiling a validated tool or a fad?] The self-assessment package features lateral thinking tests, a 'lie scale' and safety features to check for erroneous information and time-wasting. The application shuts down if users try to change test parameters. Once completed, the test works out how good staff will be at creating object-oriented applications. [Is there any basis for this assertion in fact?] A spokeswoman for Strategic Resource Solutions, the management consultancy that developed the tool for NatWest, said US research revealed 80% failure rates for staff creating object libraries. [Does anyone know of references I can look up?] [Anyone know the email/internet address for SRS?] [Do they consider TRAINING in their analysis?] [Do they consider EXPERIENCE in their analysis?] [Do they consider management support? (or lack of it!)] The software puts staff in one of three categories: those that cannot use objects to develop; those who can use objects but not invent them; and those who can invent and use them. [Are these three categories valid?] [Which one do you belong in?] [Which one do you _want_ to belong in?] The spokeswoman said 'To do object-oriented development you need a certain way of thinking which is part of your personality and you cannot change that.' [Do you agree?] [Is there any scientific basis for this?] [Can TRAINING make any difference?] In a statement NatWest Bank said: 'This is an accepted industry process that matches skills to jobs.' [Psychological testing is accepted, does it WORK?] [One implication is that if you are in the can't develop category, you're fired. What are the legal implications?] 6. Harold Chattaway - Software Metrics ------------------------------------------------------------------------ Reply To: Harold Chattaway [72540,140] First, let me thank everyone for the response my last article received on how to integrate a browse window into a screen. I am glad it was such a help to so many people. This month, I'd like to present two little programs which I hope proves to be just as useful. Also, an updated version of INTBRW.ZIP is in the 3rd Party Forum Library on the Foxuser Forum on Compuserve. The updated demo of the integrated browse now contains scroll bars for the browse. The full source code to the programs outlined here will appear on the Foxuser Forum on Compuserve. It will appear as usage.zip, Library 9 in the Foxuser Forum. Software Metrics "The Mets have a record of 10 wins and only 1 loss so far this year for games on Tuesday night... but they have won 4 out of 25 games where they were behind in the eighth inning." TV announcer Ralph Kiner, commenting on the Mets-Expos game on Tuesday, June 25, 1991 What does the above statement have to do with Foxpro development? I hope it highlights a serious shortcoming in many software development projects. That is, the total lack of any hard numbers as to what is going on! Baseball, the American pastime, a game, is a game of statistics. Almost any combination of statistics you can think of, baseball has a stat for. * How many hits in a night game by a left hander. * Shortstop fielding percentage against right handed hitters. * Batting average of any player during any time period. Can similar questions be asked of our software projects? For example: * Where are the most defects in our software occurring? * What type of error is occurring most frequently? * How many defects are occurring on a daily basis? * How many times is a particular function being called? * Are we getting sufficient test coverage of our application? While these kind of stats can be vitally important to the success of an application, they are usually missing from the equation. There is one important reason for capturing these numbers, and that is the desire to improve what you are doing. Without hard-core numbers to back up our assertions, we really do not know how our software is performing. When simple error handling and program usage tools are in place, we are able to zero in on the areas of our application that are in need of fixing. On one of my last assignments, I installed the error tracking system that I will present in this article in a rather large on-line sales order system. After the course of about week, I was able to see the patterns in the errors. I could clearly see what modules where causing the most problems. Once fixed, the apparent stability of the application greatly improved. I was able to query the error log and determine what modules where causing the most trouble. When the most frequently occurring errors are removed, the system behaves in an almost zero-defect mode. Installing an error tracking system is actually quite simple. Basically what needs to be done is to use the ON ERROR event trapper to call our tracking system in the event of an error. This switches out Foxpro's native error handler in favor of the one presented here. The line simply reads: ON ERROR DO errhand with error(), message(), message(1), lineno() This line states: "When an error occurs, call errhand.prg and pass to it the error number, the error message, the source code that caused the error, and the line number on which it occurred." The following are variables that I set up in the main program. "GNSTART" captures the starting time of the application. This is used to track how long the user had been running the app when the error took place. "GNAPPNAME" is used by the error tracking system to log in the name of the application causing the error. application caused the error. A variable is used for this purpose because this error tracking system resides in a common tools library and can be used on any numbers of projects. *--- Start time of APP... *--- Time between start and failure... gnstart = seconds() *--- Application name... gcappname = "BILLING" The structure of ERRHAND.DBF, which stores all the errors, is as follows: Field Field Name Type Width Dec 1 USER Character 10 2 DATE Date 8 3 TIME Character 10 4 APP Character 8 5 PROGRAM Character 10 6 ERRORNUM Numeric 4 7 ERRORMSG Character 50 8 CODE Memo 10 9 CURRDBF Memo 10 10 LINENUM Numeric 5 11 TOPWIND Character 10 12 APPSTTIME Numeric 10 4 13 ERRTIME Numeric 10 4 14 NOTES Memo 10 15 VIEW Memo 10 16 MEMVAR Memo 10 ** Total ** 186 The following code is the code used to capture and log in the error into errhand.dbf -------------------- ERRHAND.PRG ------------------------------------- =lusage(sys(16)) && I'll get back to this later... private cdbf, erraction, muser, i, oldsel, scrcode, topwind private errnum, errmsg, line_num, src, oldtalk, oldecho, curobj, olderr olderr = ON("ERROR") ON ERROR glnflag = iif(getenv("NFLAG")="YES",.t.,.f.) crntwind = wontop() if type('gcappname') = "U" gcappname = "" endif type() if type('gnstart') = "U" gnstart = 0 endif type() oldsel = select() cdbf = dbf() erraction = "" oldtalk = set("TALK") oldecho = set("ECHO") set talk off set echo off MUSER = GETENV("USER") STORE 1 TO i DO WHILE LEN(SYS(16,i)) <> 0 STORE i+1 TO i ENDDO src = iif(line_num>0,program(i-3),"Command Wind") scrcode = iif(line_num>0,substr(codeline,1,47),"") if crntwind != "Command Window" insert into errhand (user, date, time, app, program, errornum, errormsg, code,; currdbf, linenum, topwind,appsttime, errtime); values (MUSER, date(), time(), gcappname, src,; errnum, errmsg, codeline, cdbf, ; line_num, crntwind, gnstart, seconds()) select errhand curobj = _curobj *--- Save a .MEM file in the memo field... save to memo memvar *--- record current status and memory listing... =logenvmt() use endif This program is all that is required to track the errors occurring in your system. As the table gets more populated, queries start to become quite useful in determining where the trouble spots are. For example: SELECT program, count(*) ; from errhand ; into table prgerrs ; group by program will tell you the error count by program. Program Usage This topic has been of great interest to many developers in determining if their application has received adequate test coverage. The USAGE.APP file presented here, will first scan all of your source code and log into a table all of the procedure and functions in the entire app. It does this by opening up your project file as a DBF and scanning it looking for all project elements with a type of "P" or "s". This table can then be exported for use at runtime. The runtime portion logs into this table each and every call made to each procedure. The implementation looks like this: FUNCTION GETPRGS =lusage(sys(16)) The structure of susage.dbf is: progfile C 12 procedure C 10 callcnt N 6 The function lusage(), opens up the table susage.dbf, which is the table produced by the step discussed above. It then locates the record passed to it by the sys(16) function. Once found, the field CALLCNT is incremented by one. This function call is necessary in all functions and procedures to accurately record application usage. Once testing has begun, you can print out a bar graph showing the usage of all the procedures in the application. The bar graph is a simple Foxpro report that displays the prg file, any functions contained in it, the call count, and a bar representing the count scaled to the maximum value found in the susage.dbf table. The expression that produces the bar chart is: replicate("0",int(callcnt/(lnmaxval/80))) In case the bar graph character does not reproduce correctly in transmission, it is ASCII character 178. The 80 in the expression represents the maximum number of graph characters that can fit on the page. This report produces a bar chart with the bars running across the page and the programs listed down the left-hand side. This way the graph can continue on another page and can accommodate any number of procedures/functions. The visual insight this bar graph report gives into program usage can be quite valuable. Very quickly you are able to determine what programs are being used heavily and what programs are not being used at all. Maybe it is dead code or maybe it was just never tested. Without a tool like this, you would not know until it comes times to deliver your app to a client. I attach this program to a custom main menu pad so that is available at any time just by selecting it off the main menu. This program is a small part of a much larger data dictionary application that I have written which I will also be putting up on Compuserve, and shortly the Internet. The dictionary works in a similar way. It open up the project file and completely dissects your project into every component. It logs in tables, screens, reports, programs, table views, screen views, all index tags, and ON KEY LABEL events. It then allows the developer to document all of these items, perform application wide analysis of components, export tables for reindexing and on-line help, and also print technical documentation. I hope these two techniques discussed above, help developers in realizing what must be done in order to provide near defect free software. The field of software metrics is far more involved than what is presented here. But I hope this has at least made more people aware of the topic and what it can do for us as developers. Without some hard numbers to back up the normal testing procedure, something is bound to be missed. I highly recommend the following books for people interested in reading more about this topic: 1. "Decline and Fall of the American Programmer", Ed Yourdon, Yourdon Press, 1993 2. "Cleanroom Approach to Software Development", Mike Dyer, Wiley & Sons If you have any problems, or would like to discuss these issues further, please contact me, Harold Chattaway at SHL SystemHouse. My number is: (508)229-4884 CIS: 72540,140 Internet: hchattaway@shl.com SHL SystemHouse is one of the worlds largest systems integration companies in North America. We bring together the appropriate combination of hardware, software and communications technologies to create a fully operational system optimally meeting the unique needs of our clients. We provide programming services in SQL Server, VB, Access, Paradox, and of course Foxpro. SHL also does network design and installation, training and facilities management. 7. Ed Hartel - Closing Foxpro for Windows - NOT! ------------------------------------------------------------------------ Reply To: Ed Hartel c/o Mary Kiley CIS :73163,120 Working in FoxPro for Windows, especially when in a hurry or late into the night, I would click on a close box to close a screen or a project, when LO! AND BEHOLD!, I would double click FoxPro's close button and shut down the entire development. !@#$!. What a pain! Needless to say, this was not my favorite thing to do. To prevent this time consuming and aggravating problem from re-occurring I set up the following... I created a setup program ('setup.prg' works for me), including the lines: IF _WINDOWS MODIFY WINDOW SCREEN NOCLOSE ENDIF at the start of the program. Make sure the MODIFY WINDOW SCREEN clause will not execute in FOXPRO for DOS or an error will occur. This, of course, in addition to preventing a mislaid double click from exiting you from Foxprow, disables the use of "Alt+F4" to exit from Foxprow, but the following fixes that: 1. Create a macro for alt+f4 to contain the following: {ALT+F}{UPARROW}{ENTER} Make sure to include the curly braces. Save it to a macro file. (eg. DEVELOP.FKY) or whatever you might have set up already. 2. Include the line: RESTORE MACROS FROM filename.FKY (eg. C:\FOXPROW\DEVELOP.FKY) at the end of the setup program. NOTE: The MACRO works in both the DOS and WINDOWS platforms. So you can exit from both platforms the same way (ALT+F4). 8. View your Diary -- The Sequel ------------------------------------------------------------------------ Reply To: Brad Schulz [76640,152] San Carlos, CA USA 415-593-3224 After reading Ted Roche's submission on viewing the contents of the FoxPro diary in the October newsletter, I couldn't pass up the opportunity to exhibit some shameless self-promotion and grab some free advertising. I developed a shareware application that will print the contents of the diary in a month-at-a-glance format. In other words, one month per page, with the diary entries in the calendar boxes, like so: ========================================================================== @ @ @ @ @ @ @ @@@ @@@ @@@@ @ @ @ @ @ @ @@ @ @ @ @ @ @ @ @ @ @ @ @@@@ @@@@ @@@ @ @ @ @ @ @ @ @ @ @ @@@ @@@ @@@@@ @ @@@@@ @@@@ @@@@ @@@@ ... Wednesday Thursday Friday Saturday +-----------------+----------------+-----------------+ | 1 | 2 | 3 | |FoxPro User Group| |Billy's Birthday | |Meeting in SF @ | | | ... |7:00pm | | | | | | | | | | | | | | | | | | | /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ At least that's the way it looks like when run from FoxPro/DOS. The output looks really nice when run on the Windows platform to a laser printer, with the Month/Year title printed in the font of your choice. Anyway, if you want to check out a demo version, download the file CALPRT.EXE from the FoxForum in Library 5. As long as you're there, you might also want to take a look at CALDRS.EXE, which will print month-at-a-glance calendars for any database that has a date field. You specify the date field and an array that contains the expression(s) you wish to print in the calendar boxes and away it goes. 9. Running External Tasks in Windows. ------------------------------------------------------------------------ Author: robin (Escalation Software) E-Mail: robin.escalation@ACM.org Phone: 011-519-679-7459 EST Most of us are familiar with how the FoxPro RUN command (aka the ! command) works in DOS. The specified application is run as a shelled procedure from the calling FoxPro program. Thus: RUN /0 dostask.bat tells FOXSWAP to free up as much memory as possible and run the batch file DOSTASK. In Windows, things are a little more complicated. The on-line help only adds to the confusion, so I thought I'd experiment a little and try to discover how things *really* work. First, I tried running DOS commands. This requires setting up a PIF file in order to tell Windows how the program should be executed. I chose to run Windowed and Background for maximum flexibility and compatibility with other tasks. Also, I made sure that Close Window on Exit was selected. The following two forms of the command produced the same result (the parameter is ignored): RUN dostask.pif RUN /n1 dostask.pif The DOS task ran successfully, with FoxPro waiting until it had completed before continuing with subsequent lines of code. There seems to be no way to run the two tasks synchronously. Next, I tried running a Windows program, the Character Map applet. The simplest form of the RUN command: RUN charmap.exe produced the error "This program requires Microsoft Windows". Apparently, we must always use the /n option to launch a Windows task. So I tried: RUN /n1 charmap.exe This started up the Character Map program and returned immediately to the subsequent line of FoxPro code. By the way, the /n1 specifies how the task should run. Possible values are as follows: 1 = active and normal size 2 = active and minimized 3 = active and maximized 4 = inactive and normal size 7 = inactive and minimized The values in the PIF file (Windowed and Full Screen) are ignored. But what if we don't want to run the two tasks synchronously? In many cases, we may require that the shelled task be completed before further FoxPro code is executed. The answer to this problem lies in using Windows API calls, which we may access through FOXTOOLS.FLL. The following routine registers the GetActiveWindow function which returns a handle to the active task window, and the IsWindow function which tells us if the handle is still valid. IsWindow returns an integer representing either false (0) or true (non-zero). All we have to do is keep processing a wait state until IsWindow returns 0. In Visual Basic, we could use the DoEvents command to release control to Windows. The closest equivalent in FoxPro is INKEY(). *----------------------------------------------------------------- * Procedure:RunWait * * Description:waits until top window activity is finished * * Parameters: [none] * * Returns: [none] * * Requires: FOXTOOLS.FLL on current path * *----------------------------------------------------------------- PROCEDURE RunWait PRIVATE ALL LIKE l* SET LIBRARY TO foxtools ADDITIVE GetWindow = RegFn("GetActiveWindow", "", "I") IsWindow = RegFn("IsWindow", "I", "I") * get the handle of the active window lHandle = CallFn(GetWindow) * loop until the handle is no longer valid DO WHILE CallFn(IsWindow, lHandle) != 0 = INKEY(.1, "MS") ENDDO RELEASE LIBRARY foxtools RETURN This routine is designed to be called immediately after a RUN command, as the following test code illustrates: *----------------------------------------------------------------- * Procedure: RunTest * * Description: simple test of RunWait * * Parameters: [none] * * Returns: [none] * * Requires: RunWait * * Notes: Make sure that the PIF file directory is on the * current FoxPro path. *----------------------------------------------------------------- PRIVATE ALL LIKE l* lBegin = SECONDS() RUN /n1 charmap.exe DO RunWait WAIT WINDOW "The shell process took " +; ALLTRIM(STR(SECONDS() - lBegin)) + " seconds." RETURN We have another potential problem. If the shelled activity is very short, then the commands in RunWait may not be executed quickly enough. If the process has completed by the time GetWindow returns the active window handle, this handle will be for FoxPro itself! Hence, the loop will never end, since FoxPro cannot be closed while code is running. You can reduce the likelihood of this happening by moving the SET LIBRARY command to a routine higher in the call hierarchy. I'm sure there's more to learn about how shelled program interact with FoxPro. Those with further tips, or experience on the Mac, should feel free to e-mail me. Better yet, join the discussion on the FoxPro mailing list by sending a message to foxpro-l-request@dswi.com with "help" as the subject line. +--------------------------+------------------------------------------+ | robin | | | | -- Derain | +--------------------------+------------------------------------------+ | robin.escalation@ACM.org | FoxPro, hypertext, audio engineering | +--------------------------+------------------------------------------+ 10. SHIFTing Interface ------------------------------------------------------------------------ ReplyTo: Dan Freeman [Flash] 74140,2555 Senior Consulting Team member at Flash CreativeManagement. 201-489-2500. Always available at 74140,2555. Seasoned FoxPro developers know that you can open all of a screen's snippets by choosing "Open All Snippets" from the screen menu, or by using that menu option's hot-key (CTRL-S in DOS/WIN, CMD-N in Mac). But did you know that holding down the SHIFT key changes the menu option? Pressing SHIFT while activating the system menu turns "Open All Snippets" into "Close All Snippets", and affects the hot-key as well. You can press SHIFT-CTRL-S (in FP/DOS and FP/WIN) to tidy up your screen when those pesky snippet windows seem to take over. The SHIFT key can also cause surprises with the TEXT menu pad that appears in FoxPro/WIN and FoxPro/MAC whenever a text editing window is open. Pressing shift while pulling down the TEXT menu changes "Font" to "Screen Font". Changing the screen font during program execution can lead to errors that are bizarre and that you'll want to prevent. The under-documented NOMENU clause of the MODIFY MEMO command will prevent the Text menu from appearing. It's in the help file, but you'll have to look pretty hard to find it. It's a worthwhile exercise to cruise through the system menu, particularly the "occasional" menu pads (Browse, Text, Screen, Menu, etc.), while holding the shift key just to find out what changes. 11. BCNN Statement of Ownership, Copyright, and Responsibility. ------------------------------------------------------------------------ The BCNN Newsletter is sponsored by the Foxpro User Group of the Boston Computer Society. BCNN is dedicated to keeping professional database developers (both consultants and corporate employees) informed about educational events, meetings, job openings, world events, notable articles, technical tips, new and 'must have' products, etc. As an electronic network BCNN is also a hub where developers can address world class issues with fellow developers around the world. Recipients agree to respond via Email to periodic polls of their directions, opinions, and needs. For those who do not have User Groups in their areas, BCNN is a vehicle for individuals to volunteer and contribute to something larger than themselves. The newsletter is distributed monthly by electronic mail via CompuServe, Internet, FidoNet, and other electronic gateways. It is free of charge to individual developers. Modest fees are charged to corporations for job placement and third-party announcements. Opinions expressed are solely expressed by the Foxpro User Group or the author found in the ReplyTo of the article. No warranties are made by the authors, editors, the Foxpro User Group or BCNN regarding the accuracy or applicability of the information provided in this newsletter, nor are the above named parties responsible for direct or incidental damages due to your use of this information. All materials are copyrighted by the BCS, unless otherwise indicated, and free for any user group to redistribute on their own BBS on the condition that a by-line referencing the BCS is included. Associate Editors: ---------------------------------------------------------------------- David Rose, Days (508)538-8064, Eves (617)935-6843. CIS:73164,2263 Internet:d_rose@necx.com Arnold Bilansky Days (617)522-3700 x374 CIS:71533,1031 Internet:71533.1031@CompuServe.Com Ted Roche, CIS 76400,2503 Computer Resource, Contoocook, NH (603) 746-5670 Submissions. ---------------------------------------------------------------------- Send submissions to 73164,2263 with the subject 'BCNN Foxpro Submission'. Format your submissions similar to this letter. Distribution and Subscription Services. ---------------------------------------------------------------------- Les Squires, Director, Xbase Language Group. LSquires@WJI.Com or 73020,3435 Add Subscribers: FOX-YES to LSquires@WJI.Com. Delete Subscribers: FOX-NO to LSquires@WJI.Com. Back Issues: Library 2 of FOXUSER forum (CompuServe) Search on "BCNN". FTP WJI.Com, Login as FTP, use your ID as the password, cd fox, copy all back issues. Boston Computer Society, Inc. 101 First Avenue Suite 2 Waltham, MA 02154 617-290-5700 General Number 617-290-5700 Ext. 432 for up-to-date meeting information. WWDN(tm) World Wide Developer Network Email Services donated by Word Jenny, Inc., Boston, Massachusetts USA LSquires@WJI.Com (c) 1994 Boston Computer Society, Inc.