-------------------------------------------------------------------------- -------------------------------------------------------------------------- NNNNNNNNNNNN NNNNNNNNNNNN NNNNNNN NNNNNN NNNNNNN NNNNN 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 September 1994 A Service of the Boston Computer Society, USA Vol.1, No.6 Sponsored by the Foxpro SIG Foxpro Version -------------------------------------------------------------------------- -------------------------------------------------------------------------- Table of Contents -------------------------------------------------------------------------- 0. Introduction. 1. User Group Meetings: Last Minute Changes. 2. DevCast at DevCon NOT! - More Information. 3. Why wait for Foxpro 3.0 to have a browse object? 4. Updated UPDATED(). 5. OOP Book Review List. 6. A Foxpro Tip of the Day. 7. Jim Korenthal presents PhDBase III to BCS Foxpro Users' Group. 8. Fox DevCon '95. 9. The Great Lakes Great Database Workshop. 10. BCNN Statement of Ownership, Copyright, and Responsibility. 0. Introduction. -------------------------------------------------------------------------- ReplyTo: David Rose [73164,2263] I can't believe it's fall again! As the kids go back to school, so it is that fall is a season for new things in the adult world as well. Arnold has been busy prodding the folk at Microsoft to see what is in the works, we have technical articles from Harold Chattaway and Steven Sawyer, a reading list from Ken Levy, another Ted Roche sniplet, a product review by Adam Sacks and information on two great Foxpro events that are on the near horizon. I hope that you find our newsletter a source of inspiration for new things. Let us know how we are doing! 1. User Group Meetings: Last Minute Changes. ----------------------------------------------------------------------- ReplyTo: Arnold Bilansky [71533,1031] (617)522-3700 x374 Place: Microsoft Office, 9 Hillside Avenue, Waltham, MA USA. Meeting: September 29, 1994, 7:00 p.m. David T. Anderson "New Techniques in Rapid Application Development" Meeting: October 12, 1994, 7:00 p.m. Harold Chattaway "Slicing and Dicing PJX's & SCX's" 2. DevCast at DevCon NOT! - More Information. ----------------------------------------------------------------------- ReplyTo: Arnold Bilansky [71533,1031] BCS FoxPro SIG From: Arnold Bilansky 71533.1031@compuserve.com> To: Scott Fallon Date: Thursday, September 08, 1994 1:29AM In my last BCS/BCNN-Fox newsletter, I posted incorrect preliminary information from a MSFT source that the next DevCast would originate from FoxPro DevCon and feature FoxPro 3. In fact DevCast will be run the following week (Jan. 25?) and will exclusively feature Visual Basic 4. For FP developers, who have been assured that the release of FP3 would be accompanied by major publicity campaign, this is a stunning disappointment. It befuddles me why MSFT would not leverage the FP DevCon event for a DevCast to trumpet the most significant upgrade of FP in four years, a product sporting a MSFT look and feel along with many major enhancements. More and more FP users are looking to the FP3 release time frame as a final indication of MSFT's attitude to FP as a strategic product. Recently, we've seen FP ads, which had been a constant in DataBased Advisor, dropped. The latest issue has a front cover two page placement ad for SQL Server and a two page ad for Access, but nothing for FoxPro. I would appreciate your comments for our newsletter. #: 561 S0/CompuServe Mail 12-Sep-94 14:02 EDT Fm: Scott Fallon > INTERNET:scottfal@microsoft.com To: 71533.1031@compuserve.com Arnold: Wow! DevCast at DevCon? Where'd you get that from? The next DevCast still has not been set in terms of date, etc. All that was ever said about DevCast at DevCon was one preliminary suggestion that perhaps the two could be combined - but zero work was done beyond that. We were never going to have DevCast originate from DevCon, and we still haven't finalized logistics for DevCast. As to the launch of FoxPro 3.0 having a major publicity campaign behind it, you can rest assured there will be! This should not be viewed as a "stunning disappointment". To do so is to be looking for bad news where there isn't any. Also, the lack of FoxPro ads currently running is a PLANNED dark period (no product except perhaps Office, runs ads all the time - even Access has dark periods). We just completed a run of FoxPro 2.6 ads. And beginning next week we start a series of THREE FoxPro ads (Windows, Mac and joint with Access), including placements in DBA. Let me assure once again: Microsoft is committed to FoxPro, it is a strategic product for us, a full team is working on it, full marketing is behind it, ads are hitting in the fall, another version is coming, it is part of our long term strategic plans - THERE ARE NO PLANS TO KILL FOXPRO! Let me know if you have any other questions. -Scott 3. Why wait for Foxpro 3.0 to have a browse object? ----------------------------------------------------------------------- ReplyTo: Harold Chattaway [72540,140] SHL SystemHouse Phone: (508)229-4884 Internet: hchattaway@shl.com Download: INTBRW.ZIP from FOXFORUM Library 2 (FP-Cross-Platform) This article will explore a solution to the problem in Foxpro of integrating a BROWSE window with a READ. The solution my colleague, Joe Hilger, and I came up with, involves an idea that was presented on the MS Developers CD along with the screen utility GENSCRNX. The result is a cleanly integrated BROWSE window that can be painted on the screen using the BOX object. The following code snippets can be found in a demo of this idea in the Foxforum, Library 2 FP- Cross-Platform. The file name is INTBRW.ZIP. This zip file contains the demo for this idea as well as GENSCRNX and the 3d driver for GENSCRNX. Unzip these into a directory, bring up Foxpro and just type DO INTGBROW in the command window to see how it looks. When you are ready to experiment with the example, you will need to unzip GENSCRNX.ZIP as well as 3DFOX.ZIP. Then make the changes to your config.fp? file as outlined below. This demo is for Windows and DOS. It looks much nicer in Windows! Currently at SHL SystemHouse in Marlboro MA, we are working on an accounting package in Windows, that will service the agriculture business in the Northeast section of the country. Initially, the idea of using an integrated BROWSE to represent the child database in a header/detail screen seemed very appealing but very difficult to implement. When it became clear that many screens would benefit from this approach however, our manager Joe Holland, decided that it would be worth our while to invest more time in the BROWSE approach. Our first major concern was integrating the BROWSE with the window so that when the user moved the main window, the BROWSE would follow along. Most solutions involve making the browse window separate from the GET window. This was not acceptable however. We required that they move together. The solution on the MS Developers CD suggested to make one large "container window", one get window inside the container window, and another window in the container window that would be for the BROWSE. This solved the problem of having the BROWSE window =#S$W-]4 the container window. The GET window would be defined with no border so as to make it appear as though the GETs were being issued in the container window. Since the container window has no GETs issued in it, and the other defined windows are not overlapping, there was no concern about one window obscuring another window when it had focus. This approach still leaves for cumbersome programming. How does one define the GET window and the BROWSE window in such a way as to retain the benefits of using the screen builder? i.e. Allowing for container window resizing without hand-coding the changes to the GET and BROWSE windows. This is where our idea and GENSCRNX by Ken Levy, comes into play. GENSCRNX allows the developer to make use of vital screen object information available at generation time. Since this information is maintained by the screen builder, the developer need only extract out the information at generation time. Our solution involves using the *:FUNCTION, *:DELOBJ, directive and the {{ }} operators in the comment snippet of a BOX object. To define the window that holds the GET's we draw a BOX object in the upper half of the screen. By double-clicking on the box once it is sized, you gain access to the comment snippet. In the comment snippet we placed the following code: *:function defwgets *--- This window will hold the GETs. *--- Defined with no border so it looks part of the container window. *--- Will take on same color as container window. See SETUP code *--- for lccolor. *--- VPOS, HPOS, HEIGHT, WIDTH are fields in the SCX file that *--- defines the box object. define window wgets at {{VPOS}}, {{HPOS}} size {{height}}, {{width}} ; in window wbig none color &lccolor font "FOXFONT", 7 *:delobj The *:function directive will place a function called DEFWGETS in the cleanup code of the screen. By placing these directives in the comment snippet of this box object, the box VPOS, HPOS, HEIGHT, and WIDTH values will be available when GENSCRNX is evaluating this record during the generation phase of this screen. The {{ }}, tells GENSCRNX to evaluate the field contained inside of braces at generation time, and insert these values into the generated code. This technique allows for the visual placement of a window in a window while retaining the benefits of using the screen builder. If the window needs to be resized to hold more objects, simply resize the box. At generation time, the new values will be used to define the window to exactly match the boundaries of the box object! Similarly, this technique can be used to "paint" a BROWSE window on the screen. In the lower half of the screen, we painted another box object which has the following code in its comment snippet: *:function defwbrowse lccolor = iif(_dos,"SCHEME 10","rgb(,,,192,192,192)") lcwinclause = iif(_DOS," NONE","") *--- Browse window will take its position and size from this *--- box object. define window wbrowse at {{VPOS}}, {{HPOS}} ; size {{HEIGHT}}, {{WIDTH}} ; in window wbig color &lccolor font "FOXFONT", 7 &lcwinclause *:delobj In both comment snippets, the *:DELOBJ directives are needed so the box itself is not drawn on the screen. Since both these functions are generated in the cleanup code, they may be called from the setup code for the same screen. This will actually define the windows and place them within the "container" window. The following two lines will define the windows: =defwgets() =defwbrowse() To make the BROWSE window even more appealing in the Windows environment, a second BOX object can be defined around the BOX object that defines the BROWSE window. The comment snippet for this second box can contain: *:3d 4 BOX This will create a raised 3D effect around the BROWSE window. It adds a very appealing look to the screen! If you need to place other GETs on the screen that are not in the WGETS window ( push buttons along the bottom of the screen ), simply draw a box where you need the other objects to be placed. In the comment snippet of the box, place the following code: *:window wpushbutt define window wpushbutt at {{VPOS}}, {{HPOS}} ; size {{HEIGHT}}, {{WIDTH}} ; in window wcontainer color &lccolor ; font "FOXFONT", 7 &lcwinclause Then place the new get objects within the box object. We wrote a new GENSCRNX driver that will look for box objects and update the coordinates of all get objects that fall within its boundaries so that the position of the get objects are relative to the top left corner of the box and not the main screen. Remember, no get objects can be written to the container window. So all get objects must reside in their own window which in turn is inside of the container window. Regular box objects and text can be placed directly in the container window since these will never have focus. In order for this to work however, the container window needs to be active at the time they are written. So POSGETS will examine all objects, and any objects that are box objects or says will be written to the container window. It will insert code just before the say/box is written, that will activate the container window. In order for POSGETS to know what window is the container window, in the setup code for the screen, place the following directive: *:window wcontainer POSGETS will look for this and use whatever name appears after *:WINDOW as the window name to activate. Also in the setup code it is necessary to manually define the "container" window. The container window will actually be the window that would have been defined by GENSCRN. Since GENSCRN would normally generated code that makes this main window the active window just before the GETs are issued, we need to fool GENSCRN. The name of the window we assign to the main window will actually be "WGETS" not "WCONTAINER". WCONTAINER we will define in the setup code. Using the power of GENSCRNX, we can extract out the information about the main window from the SCX table. The container window definition code is: lccolor = iif(_dos, "SCHEME {{scheme}}","rgb(,,,{{fillred}}, ; {{fillgreen}}, {{fillblue}} )") define window wbig at {{VPOS}}, {{HPOS}} size {{HEIGHT}}, ; {{WIDTH}} ; color &lccolor float ; font "{{trim(fontface)}}", {{fontsize}} title {{tag}} When GENSCRNX is generating the setup code, it is sitting on the record in the SCX table that contains the information about the main window! This is why we can pull out information about the main window position, size, and color attributes. Since we are defining the window here, uncheck the box on the screen set dialog that would generate the window definition and release window code. Please reference the sample application INTBRW.ZIP for a working demonstration of this approach in both DOS and Windows! The easiest way to take advantage of the 3d driver and the POSGETS driver, is to reference them in your config.fpw file like this: _SCXDRV5="\3d.prg" _scxdrv4="\posgets.prg" In order to use GENSCRNX, the environment variable _GENSCRN must point to where GENSCRNX is located. Doing it this way instead of in the setup code of your screens, make the code more portable. You can simply change the config file if you move the code to another machine or directory instead of changing all references in the setup code for each screen. So, as you can see, tapping the information that is contained in the SCX table at generation time, allows for some very simple solutions to some very important but tough development issues. I greatly urge all Fox developers to make themselves aware of the information that is contained inside the power tool tables. If you have any problems, or would like to discuss these issues further, please contact myself, Harold Chattaway, or Joe Hilger 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. 4. Updated UPDATED() -------------------------------------------------------------------------- ReplyTo: Steve Sawyer [75730,455] President, Detroit Area Fox User Group When we create a screen with an "edit" mode, we have to handle the cases where the user cancels the editing operation or closes the window. We can pop up a dialog asking the user if they want to cancel the changes they have made. However, do we want to *always* ask the user if they want to cancel changes, even when they *haven't* made any changes to the data? What if they make a change and then change the value back to it's original value? I don't know about you, but I find the type of "dumb" software that always assumes I've made some change and forces me to confirm that I want to cancel an operation in *all* cases a little annoying. FoxPro has an UPDATED() function that is intended to determine if any changes were made to fields in a READ. However, two problems exist in making practical use of UPDATED(). First, if you have push-button controls in the screen itself, the very act of selecting the "Cancel" button changes the value returned by UPDATED() to .T.. This can be worked around by checking the value of UPDATED() in the WHEN clause of the "Cancel" push-button, and setting a logical memvar to reflect the state of UPDATED() upon entry into the push- button control. However, there is a second problem with the operation of UPDATED(). Some developers (such as myself) issue a SHOW GETS in the VALID clause of each field, relying on our READ SHOW code to validate the information in all of the fields, and activating and deactivating fields and controls based on the values already entered in those fields, or on the current settings of various controls. Issuing a SHOW GETS "resets" the state of UPDATED() to .F. until another value is changed! What follows below is a function I whipped up to detect when changes to data in a screen populated with SCATTER MEMVAR MEMO has been changed: *--------*---------*---------*---------*--------- * Function..........: CHANGED *) Description.......: Used to determine if SCATTERed *) ..................: memvars have changed * Syntax............: To initialize: * ..................: DIMENSION ),2]) * ..................: SCATTER MEMVAR MEMO * ..................: DO CHANGED WITH , * ..................: To determine whether any memvar has * ..................: changed: * ..................: llChanged=CHANGED(@) * Parameters........: paArrayName, Array, Memvar names and * ..................: values * ..................: pcAlias, Character, file used in SCATTER * ..................: MEMVAR command to create memvars being * ..................: compared * Uses..............: * Returns...........: jlChgd, logical when called as function * Calls.............: * Changes...........: * Called By.........: *--------*---------*---------*---------*--------- FUNCTION CHANGED PARAMETERS paChkArray,pcAlias PRIVATE LIKE j* jlChgd=.F. IF TYPE("paChkArray[1,1]") = "L" jcCurrArea=ALIAS() SELECT (pcAlias) =AFIELDS(jaTmp) FOR i=1 TO ALEN(paCHkArray,1) paChkArray[i,1] = "m." + TRIM(jaTmp[i,1]) paChkArray[i,2] = EVALUATE(paChkArray[i,1]) ENDFOR IF ! EMPTY(jcCurrArea) SELECT (jcCurrArea) ENDIF ELSE FOR i=1 TO ALEN(paChkArray,1) IF EVALUATE(paChkArray[i,1]) # paChkArray[i,2] jlChgd = .T. EXIT ENDIF ENDFOR ENDIF RETURN jlChgd *EOF CHANGED I use this function to enable and/or disable a "Save" push-button, and to determine whether some confirmation should be requested in response to the user selecting "Cancel". First I do a little preparation for this function by DIMENSIONing a two-dimensional array to 2 columns, and as many rows as I have fields in the table that I'm SCATTERing from. Note that use of a FIELDS clause will prevent CHANGED from working as written - it assumes that all fields are being SCATTERed. Next the current record is SCATTERed. Note that CHANGED() can also be used when the user is canceling a new record when SCATTER MEMVAR MEMO BLANK is used. In some cases (particularly when adding a new record) some of these memvars are initialized to some value. If this is the case, I do these initializations as the next step, or at least before CHANGED is called for the first time. At this point we have our "unchanged" memvars, and a "reference" array of the proper dimensions, with all the elements initialized to the default .F. value. To initialize things with respect to CHANGED, it is called as a procedure, passing the name of the array and the alias that we have SCATTERed the screen memvars from as parameters: DO changed WITH ,
Because CHANGED sees that the first element of the passed array has a logical value, it "knows" that we need to populate the elements of the array. (One of my practices is that logical values in a table always go at the end, or immediately after a field to which they directly relate, therefore none of my tables ever have a logical initial field). CHANGED then proceeds to populate a temporary array (jaTemp) with the names of the fields in the table, and uses this array to populate the (currently empty) reference array with the memvar names by prepending "m." to the field name. CHANGED then populates the second column of the reference array with the current value of each of the SCATTERed memvars. Because at this point we have called CHANGED as a procedure, parameters are passed by *REFERENCE*, and any changes made to the array passed to it are "permanent" and persist after we return from the procedure. Once this is accomplished, I can call CHANGED as a function at any time, and it will tell me whether the user has made any changes to any of the fields SCATTERed: llChanged = CHANGED(@) Because we are now calling CHANGED as a function, it is necessary to insure that the array is passed, again, by reference, so that the entire array and not just the value of the first element is passed. To "force" this behavior (variables are passed to functions, by default, by *value*), we prepend the "@" symbol to the name of the reference array. Since the array being passed is populated with the names and original values of the memvars, the alias of the original table is not necessary (and ignored if passed), and CHANGE simply executes a FOR...NEXT loop, comparing each memvar to the original value held in the reference array, and returns a .T. if it detects *any* change, and .F. if nothing has changed. If all of the SCATTERed memvars are changed *back* to their original values, CHANGED again returns .F. A couple of additional notes on my use of CHANGED. If some of my screen controls are popups or picklists or textual fields using the "@M" function in the PICTURE clause, or any other control whose variable is not the SCATTERed memvar, the corresponding memvar must be immediately updated in the VALID clause of that screen control. For instance, I have a single-character field indicating shipping method, "Y","M","U", "C","O" which correspond to an on-screen popup populated with the corresponding prompts "Your Truck", "Motor Freight", "United Parcel", "Customer Pick-Up" and "Other". The valid clause of this popup immediately changes the m.cshipby variable to the proper value. I check the value of CHANGED() in the READ SHOW code, called by a SHOW GETS in each field or screen control so that the "Save" button can be enabled if any changes are made, and CHANGED() is also checked in the VALID code for the "Cancel" push button, to see if we want to ask the user if they want to cancel the changes they have made to the record. If no changes have been made, the READ is cleared and the screen is closed without further action on the part of the user. Steve Sawyer President, Detroit Area Fox User Group 5. OOP Book Review List -------------------------------------------------------------------------- ReplyTo: Ken Levy [FLASH] 76350,2610 The following is a list of books that I own which related to object-oriented analysis, design, and programming. Understand that I have not read every one of them completely, but have browsed and/or referenced them in detail. Most OOP books are somewhat designed to be referenced rather than being read like a novel. Unless otherwise stated, they do not relate to any particular OO language. This list is not a sales pitch and does not contain any type of biased comments. Instead, it's simply a global response to many questions I've received asking for advise on reading material that can be obtained in preparation for object- orientation coming in FoxPro 3.0. This document can be freely distributed or re-printed as long as it is not altered in any way. It is important to realize that learning about object technology is independent of learning any languages or development tools. You should not plan on learning object technology from the syntax of a programming language that supports OOP. The key is to learn object-oriented concepts and design independently of any OOP language implementation. After obtaining a complete understanding of object-oriented analysis and design concepts and definitions, then select an OOP language to implement object-oriented applications. For getting an introduction to object-orientation, the minimum recommendation is reading the first two books listed. When ready to implement object-oriented applications, it is recommend that the third book listed is obtained for methodology and implementation issues. The others can be selected based on requirements, interests, etc. Object-Oriented Technology: A Managers Guide by David A. Taylor, Ph.D. Publisher: Addison-Wesley ISBN 0-201-56358-4 Object-Oriented Systems Design: An Integrated Approach by Edward Yourdon Publisher: Yourdon Press Computing Systems ISBN 0-13-636325-3 Object-Oriented Analysis and Design with Applications, Second Edition by Grady Booch Publisher: Benjamin/Cummings Publishing ISBN 0-8053-5340-2 Object-Oriented Software Engineering: A Use Case Driven Approach by Ivar Jacobson Publisher: Addison-Wesley ISBN 0-201-54435-0 Practical Applications of Object-Oriented Techniques to Relational Databases by Donald K. Burleson Publisher: Wiley ISBN 0-471-61225-1 Object-Orientation: Concepts, Languages, Databases, User Interfaces by Setrag Khoshafian and Razmik Abnous Publisher: Wiley ISBN 0-471-51801-8 Object-Oriented Information Systems: Planning and Implementation by David A. Taylor, Ph.D. Publisher: Wiley ISBN 0-471-54364-0 Object Technology in Application Development by Daniel Tkach and Richard Puttick Publisher: Benjamin/Cummings Publishing ISBN 0-8053-2572-7 Object Data Management: Object-Oriented and Extended Relational Database Systems by R.G.G. Cattell Publisher: Addison-Wesley ISBN 0-201-53092-9 Code Complete by Steve McConnell Publisher: Microsoft Press ISBN 1-55615-484-4 Object Magazine Publisher: Sigs Publications 6. A Foxpro Tip of the Day -------------------------------------------------------------------------- ReplyTo: Ted Roche [76400,2503] The BCS was fortunate enough to have Mac Rubel in January of this year, (if you haven't seen his slideshow of 'The Cockroach Coda to Murphy's Law,' 'The Siamese Twin Rule,' 'The Expanding Universe Theorem' you're in for a treat!) and at one point in our conversation, he griped about the fact that Fox didn't have a 'Tip of the Day' option like Word or Excel. Now, this discussion was focused on the idea that Fox is a poor step-child in the MSFT family, and bears no relationship to reality, nor to the idea that any of us would actually _want_ such a thing. Such disclaimers aside, no sooner than you can shout "Challenge Me!" I was away to the keyboard. The following sniplet is added to my startup routine, with the limitation of only appearing early in the morning. There are some clever ways to make it appear only once, but I chose brevity over cleverness, with: if TIME() < "08:30" do HelpTips endif ***************** * HelpTips.PRG * * Written by: Ted Roche, inspired by Mac Rubel @ BCS * * Date Written: 02/22/94 * * Purpose: Popup a randomly chosen Help topic, a 'tip of the day' * Assumptions: there must be a help file set with SET HELP TO * there must be a free work area, free memory, * file handles, the first help field must be "topic" * (this could be fixed with an AFIELDS() and * EVAL(Arr[1,1]))* PRIVATE lnSelect, lcTopic && declare privates lnSelect = SELECT() && preserve work area USE (SET('HELP',1)) AGAIN IN 0 NOUPDATE && open the help file in free area GO (RECCOUNT() * RAND(-1)) && jump randomly lcTopic = topic && ASSUMES 'topic' field exists USE && close the help file SELECT (lnSelect) && restore the work area SET TOPIC TO lcTopic && position the help topic HELP NOWAIT && display the help 7. Jim Korenthal presents PhDBase III to BCS Foxpro Users' Group. -------------------------------------------------------------------------- ReplyTo: Adam D. Sacks [75037,2014] Phone: 1-800-KA-PROGS (Korenthal Associates) At the June 1994 meeting, Jim Korenthal demonstrated PhDbase III (tm), his full text retrieval utility for FoxPro. And a remarkable demonstration it was. PhDbase first indexes a new file, which in the case of the FoxPro 2.5 help file, for example, takes about 1.5 minutes for 2.5 MB, and then updates it transparently whenever it's modified. Then, when you perform a search, it's virtually. It will index character, memo, numeric, and date fields, numeric expressions and external files; find related words and process word exclusion lists. It creates index files approximately one-tenth the size of the indexed files. It works in both Windows and DOS, and the networkable version, although not ready at the time of the workshop, was due out soon (and a free upgrade from the single-user version). In a word, it was impressive. At a royalty-free $299.95, it's a pretty inexpensive way to add an excellent feature to your applications, and smiles to your clients' faces. Contact Korenthal Associates at 1-800-KA-PROGS (1-800-527-7647). 8. Fox DevCon '95. -------------------------------------------------------------------------- Phone: 1-800-MFOX-PRO (1-800-636-9776) Outside the US 612-593-0677 Fax: 612-550-4595 Email: msevent@cci.cmgt.carlson.com Mail: PO Box 59159, Minneapolis, MN 55459-8284 This week Microsoft mailed over 200,000 postcards worldwide announcing the 1995 Microsoft FoxPro International Developer Conference. The conference will be held at the San Diego Convention Center, in San Diego, California, January 16 - 19, 1995. This year's conference has been extended an extra day to ensure you will able to attend all your favorite sessions. With so much to talk about this year, DevCon is sure to be more information packed than ever! DevCon is a product-focused technical conference with strategic learning opportunities. An assembly of key Microsoft personnel and FoxPro enthusiasts with major roles in all areas of FoxPro creation, development and utilization will be presenting at the conference. In addition to hearing from the experts, DevCon provides an opportunity-rich environment for sharing information with your fellow FoxPro users. Conference activities: -- General sessions by Microsoft executives with daily briefings by industry luminaries. -- Over 50 in-depth sessions where you can learn more about specific areas of the product. -- Product focused third-party trade show/exhibition. -- Hands-on programmers' exchange where you can play with the latest products. -- Social networking opportunities. IF YOU USE FOXPRO, YOU ARE STRONGLY ENCOURAGED TO ATTEND. Conference Registration Before 11/15/94: discount conference fee of $995 After 11/16/95: regular conference fee of $1295 To get additional information or to register for the conference you can use one of the options below. The registration representative can also make your hotel and airline reservations, all with just one phone call. So, watch your mail box for your DevCon postcard. [It will be the funky gold colored piece in your mail pile. You can't miss it!] 9. The Great Lakes Great Database Workshop -------------------------------------------------------------------------- ReplyTo: Whil Hentzen [70651,2270] Phone: 414.332.9876 Fax: 414.963.4999 The Great Lakes Great Database Workshop, featuring over 60 sessions on 6 tracks covering Access, FoxPro, Visual Basic, SBT and other vertical packages, MIS and consulting, and third party add-ons and will be held in Milwaukee on Friday, November 11 and Saturday, November 12. $125 by Saturday, September 17. $150 by Saturday, November 6. $175 after November 6, including day-of-workshop. Price includes lunch both days. Space (and a nasty editor ) prohibits us from listing all topics - see below for how to find out more. The cast of characters include Access wizards Robert Green, Mike Harding, Leslie Koorhan, Bernadette Lantz and Paul Nielsen, FoxPros Tamar Granor, Val Matison, Mike Beane, Dick Bard, Steve Black, Doug Hennig, Mike and Toni Feltman, Leslie Koorhan, Ted Roche, Frank Donovan, Drew Speedie, John Hosier, Robert Green, Visual Basic mavens Art Edstrom, Walter Grogan, Richard Knudson and Zane Thomas, and Dave Cranford, Jack Gallagher, Max Hirsch, Bob Kehoe, Dick Pierson, Duane Robbins for the vertical and MIS/Consulting topics. The GLGDW is sponsored by Microsoft, Pinnacle Publishing, SBT, the Milwaukee Association of FoxPro Developers and the Milwaukee Area Visual Basic Users Group. For more information, including a 16 page brochure containing full session descriptions, speaker bios and other details, call 414.332.9876, fax 414.963.4999, or email CompuServe 70651,2270. 10. 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. Over 7,500 persons world-wide participate with CA-Clipper, Microsoft Access and FoxPro. 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:david@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-4017 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. BCNN Email Services donated by Word Jenny Inc. LSquires@WJI.Com (c) 1994 Boston Computer Society, Inc.