FILES - MANAGING NUMBER OPEN

In message Mon, 17 Apr 95 03:03:05 PDT,
  Dan Dunning <ir001991@interramp.com>  writes:

> in earlier versions of foxpro, most notably foxpro 1.02 and foxpro for
> the mac, there was a limit to the number of open tables.  i believe the
> limit was 10 and then 25.  with the new version, 2.6, many more tables
> are allowed to be open at a time.

Actually, the limit was extended to 225 with ver 2.5 and 32K with VFP.

> if the database wasn't opened when initially, then i close the database
> upon leaving the routine.  with the new version, should i just open all

This isn't necessarily necessary, and it will serve to slow down the
computer if you keep opening/closing databases.

> opening them all at once would allow me to always issue a SELECT instead
> of a GET_BUFF, and probably would run faster.  However i am unsure of the
> trade-offs.  I assume that a large setting for FILES and BUFFERS in the
> config.sys file must be issued.

Using BUFFERS as a disk cache is terribly inefficient.  Better to go with
SMARTDRV if you have > 4Mb.

I generally have an array set up that is as big as I think I will need (one
row per SELECT area).  This array holds the list of open databases that I
care about.  WHen I want to open a new database, I 1) check to see if it's
open, 2) if not, then I see if I can fit it in the array, 3) if not, then I
extend the array, 4) if I can't do that, then close the database that was
open the longest time ago that's not needed now.

Of course, I also keep a certain number of areas available for any SELECT --
SQL work, and I check for aliases.  This works fairly well, and is quite
quick.  By prefixing open database names with "D_" and aliases with "A_" in
the array, it makes finding stuff really quick.  And by starting off with a
25 row array and only adding a row when necessary, it also makes things
quick.

/Paul

--
+-------------------------+----------------------------------------------+
| Paul Russell            | Phone: 902-481-4582    Fax: 902-468-3679     |

FIRING DELAY FOR LISTBOX WHEN()

Date: Thu, 23 Feb 1995 16:14:15 -800
From: tcallah@eval.iupui.edu (Timothy A. Callahan)
Subject: Re: Screen list box question

Thanks to Cindy Gorsuch, I now have the article from Sept 94 FoxPro Advisor
which answers my question about pausing before firing the listbox's WHEN
snippet.  I have included the code from Steven Black's article to place in
the listbox's WHEN snippet.  Thanks for everyone's help!

PRIVATE llchar, lnchar
llchar = CHRSAW(_DBLCLICK)

IF llchar
  lnchar = INKEY()
  IF lnchar = 5 OR lnchar = 24
    IF lnchar = 5
      KEYBOARD "{UPARROW}" PLAIN
    ELSE
      KEYBOARD "{DNARROW}" PLAIN
    ENDIF
    RETURN .T.
  ENDIF
ENDIF

* Rest of WHEN code below:


Timothy A. Callahan
tcallah@eval.iupui.edu

FLL - C++ CODE FOR CHILD 'WINDOWS' WINDOW

SUMMARY
=======

As shown below, you can use the FoxPro Library Construction Kit to create a
child "Windows" window that can be manipulated within FoxPro. Using this
method, you can create a window procedure that can receive Windows messages
such as WM_PAINT.

MORE INFORMATION
================

FoxPro Sample Code
------------------

SET LIBRARY TO Showind.fll
=ShowTheWind()

C Sample Code
-------------

#include 
#include 

HINSTANCE hinst,mhinst ;
char szClass[] = "Class";
HWND hwndWindow = NULL;
MSG msg;
WNDCLASS wc;

long FAR PASCAL WndProc(HWND hWnd, UINT message, WORD wParam, LONG lParam);

HINSTANCE Inst;

void ShowTheWindow(ParamBlk FAR *parm)
{
   wc.style=0;
   wc.lpfnWndProc=WndProc;
   wc.cbClsExtra=0;
   wc.cbWndExtra=0;
   wc.hInstance=Inst;
   wc.hIcon=NULL;
   wc.hCursor=NULL;
   wc.hbrBackground=(HBRUSH)(COLOR_BACKGROUND + 5);
   wc.lpszMenuName=NULL;
   wc.lpszClassName=szClass;

   if(!RegisterClass(&wc))
      return ;
   hwndWindow = CreateWindow(szClass, "This is a child Window",
      WS_OVERLAPPED | WS_SYSMENU | WS_BORDER | WS_MINIMIZEBOX,
      CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT,

   FindWindow(0,"Microsoft FoxPro"), NULL, Inst, NULL );
   ShowWindow(hwndWindow,SW_SHOW);
   UpdateWindow(hwndWindow);
}

long FAR PASCAL WndProc(HWND hWnd, unsigned message,WORD wParam, LONG
lParam)

{
   PAINTSTRUCT ps;
   switch (message)
   {
      case WM_DESTROY:
         PostQuitMessage(0);
      case WM_PAINT:
         BeginPaint(hWnd,(LPPAINTSTRUCT)&ps);
         EndPaint(hWnd,(LPPAINTSTRUCT)&ps);
      default:
         return DefWindowProc(hWnd,message,wParam,lParam);
   }
return(0L);
}

FoxInfo myFoxInfo[] = {
{"SHOWWIND", (FPFI)ShowTheWindow, 0, ""},
};

FoxTable _FoxTable = {
{FoxTable FAR *)0, sizeof(myFoxInfo) / sizeof(FoxInfo), myFoxInfo
};

REFERENCES
==========

Microsoft FoxPro Library Construction Kit "Developer's Guide," version 2.5
Microsoft Visual C++ "Programmer's Reference, Volume 2: Functions"
"Programming Windows 3.1," Microsoft Press

FLL - HOW TO COMPILE USING VISUAL C++

Below are step-by-step instructions for compiling a .FLL file using
Visual C++ version 1.0 and FoxPro Library Construction Kit (LCK)
version 2.5.

MORE INFORMATION
================

 1. From the VC Workbench menu, choose Project -> New to bring up the
    New Project dialog box.

 2. In the New Project dialog box, choose Project Type = Windows
    dynamic-link library (.DLL). Close the dialog box.

    When you close the New Project dialog box, the Edit - 
    dialog box is presented.

 3. Select each of your C API source modules for inclusion in the
    project.

 4. Select PROAPIML.LIB (Type: .LIB) from the LCK directory.

 5. From the VC Workbench menu, choose Options -> Project, which
    brings up the Project Options dialog box.

 6. From the Project Options dialog box, choose Compiler.

 7. From the Category list box, select "Full (using Program database)".

 8. Close the Compiler Options dialog box.

You are now ready to build the .FLL.

The output file will have a .DLL extension. After compilation, you can
test the newly created module by renaming the file with an .FLL
extension or by issuing the following command:

   Set Library to .DLL

Additional reference words: FoxWin 2.50 LCK Visual C C++ Library
Construction Kit fll unresolved external
KBCategory: kbtool kbprg
KBSubcategory: FxtoolLck

=============================================================================

FLL - MAKE MOUSE VISIBLE IN C++ DEBUG

SUMMARY
=======

When you are attempting to debug a .FLL file, the mouse pointer will
disappear while the debugger is active. Furthermore, when a Windows dialog
box is used, the mouse will be disabled.

MORE INFORMATION
================

To avoid this problem, add the Windows ShowCursor() function to the .FLL
file. You can also use this technique to make the mouse active when calling
Windows dialog boxes.

The following example calls the Windows Printer dialog box and makes it
modal to Foxpro by passing the handle to the FoxPro window through the
MainHwnd() function found in FOXTOOLS.FLL.

Sample Code
-----------

FoxPro Code:

   SET LIBRARY TO Foxtools.fll
   SET LIBRARY TO Printdlg.fll ADDITIVE

   =printdlg(mainhwnd())


C Code:

   #include 
   #include 
   #include 


   void FAR printdlg(ParamBlk FAR *prt)
   {
        static     PRINTDLG pd;
        ShowCursor(TRUE);
       pd.lStructSize = sizeof(PRINTDLG);
        pd.hwndOwner   = (HWND)prt->p[0].val.ev_long;
        pd.hDevMode    = NULL;
        pd.hDevNames   = NULL;
        pd.Flags       = PD_RETURNDC;
        pd.nMinPage    = 1;
        pd.nMaxPage    = 1000;
        pd.nCopies        = 1;

        PrintDlg(&pd);
        ShowCursor(FALSE);
   }


   FoxInfo myFoxInfo[]={
        {"PRINTDLG",(FPFI)printdlg,1,"I"},
   };

   FoxTable _FoxTable={
   (FoxTable FAR*)0, sizeof(myFoxInfo) / sizeof(FoxInfo), myFoxInfo
   };

REFERENCES
==========

FoxPro Library Construction Kit "Developer's Guide," version 2.5

Additional reference words: FoxWin 2.50 2.60 API
KBCategory: kbinterop kbtool kbprg kbcode
KBSubcategory: FxprgFoxtools

FLL MESSAGEBOX - MODAL

        I often use the function "MessageBox" in FOXTOOLS.FLL in my apps
(FPW 2.6). It works fine but I don't know how to prevent the user from
clicking outside the MessageBox window. When this happens, the window seems
to disappear (i.e. it goes under the current one).

        Is there any way to make it modal?

N.B.: I use commands like these:
        MessBox=RegFn("MessageBox", "ICCI", "I")
        BoxRt=CallFn(0, Messbox, "...text...", 32+1)

<---- End Included Message ---->

You need to include the Window handle instead of passing 0 as your first
parameter. This will make the dialog box modal to the window that you pass to
it.  For a simple test, try also using the API function GETACTIVEWINDOW() which
takes no parameters and returns a handle to the currently active window.  Then
pass this handle to your MessageBox function.

-= Ken =-

************


>N.B.: I use commands like these:
>        MessBox=RegFn("MessageBox", "ICCI", "I")
>        BoxRt=CallFn(0, Messbox, "...text...", 32+1)

James,

Long shot - but try adding 4096 to whatever other integers you are using to
define the box. In VB this makes the box System Modal, by default it should
be application modal.

Good luck,
 --------------------------------------------------------------------
 Miles Thompson                                           P.O. Box 82

FLL's

>> Just for the hell of it I tried to 'Set Library to' other standard Windows
>> DLLs, but I just got the error "Invalid Library..." Does anybody know why?
>> From the documentation it seems like I should be able to do this.

>FoxPro libraries (.FLL files) are run by FoxPro itself (sort of).
>Windows libraries (.DLL files) are run from the Windows kernel.  The
>FoxPro .FLLs are able to call the functions in the Windows .DLLs, but
>the .DLLs cannot be accessed from FoxPro directly.

>/Paul

I use other DLL's all the time.  The trick is to specify the DLL name in the
call the RegFn().  For example I have the following function that I use which
uses Novell's Netware API, NWNETAPI.DLL:

#Define NwDllOld    'NWNETAPI.DLL'
Function MapNetDrive
  *** Parameters:
  *** nConnId      = Connection ID of server to which search drive is to be
  ***                mapped. If invalid, the drive will be mapped for the
  ***                default server.
  *** cPath        = String containing the path to be assigned to cDrive (Max
  ***                254 chars, a NUL, Chr(0), will be added to the end before
  ***                passing to the Netware function.)
  *** nAddDelIns   = DRIVE_ADD, DRIVE_DELETE or DRIVE_INSERT
   *** nSearchOrder = Search drive order number, 1-16.  Pass 0 to map a normal
  ***                (non-search) drive.
  *** cDrive       = Pointer to drive letter ("A" to "Z").  Don't include a
":".

  ***
  *** Return Values (Defined in Netware API docs):
  *** SUCCESSFUL
  *** VOLUME_DOES_NOT_EXIST     (Add, Insert)
  *** INVALID_PATH
  *** SEARCH_DRIVE_VECTOR_FULL  (Insert)
  *** DRIVE_IS_NOT_MAPPED       (Delete)
  *** NO_DRIVE_AVAILABLE

  Parameters nConnId,cPath,nAddDelIns,nSearchOrder,cDrive

  Private MapDrive
  MapDrive = RegFn('MapDrive','ICCCI@C','I',NwDllOld)
Return CallFn(MapDrive,nConnId,NO_BASE_DRIVE,cPath+Chr(0),;
              nAddDelIns,nSearchOrder,@cDrive)

FOXPRO COMPILER

  >Is there such a thing as Clipper for Fox 2.6/Win? It would be
>nice to have a true compiler for this code, so I didn't have to
>lug around a 3 MB ESL file and all the overhead.

Foxkit for FlagShip is just such an effort.... it should work with Clipper
 too...... any takers on helping to enhance it?

It is available for free on my ftp server.... see my .sig

Mark Bolzern :  mark@gcs.com    USA Tel: (303) 699-7470  Fax: (303) 699-2793
WorkGroup Solutions, Inc.    The FlagShip "CA-Clipper and XBase on Unix" People
  FlagShip is a 4GL Database Development System & XBase Porting Tool for Unix
No Runtime Fees   Info at ftp.wgs.com : /pub2/wgs/Filelist OR mail:
info@wgs.com

 **
 The Force Database compiler may be just what S Stoner is looking for.
Try GO FORCE in Compuserve for more information.  I have used FORCE
for over a year now and have had great results.

FOXPRO HISTORY

The actual chronology of Fox Software's products prior to the acquisition by
Microsoft was:

FoxBase		1984	MSDOS
	This was a dBASE II work-alike

Multi-User FoxBase	1985	MSDOS & UNIX
	Also a dBASE II work-alike but with primitive multi-user features

FoxBASE+		1986	MSDOS
	A dBASE III Plus work-alike that (together with a celebrated lawsuit) 	helped
put Fox Software on the map.

FoxBASE+/Mac		1987	Macintosh
	This first Macintosh product of Fox Software's captured a majority
	the Mac database market within a few months of its release.
	It could be viewed as an initial design study for the first MSDOS
	version of FoxPro in 1989-90.

FoxPro			1989	MSDOS
	This product supported a superset of the dBASE IV language but
	an entirely new interface most similar to that of FoxBASE+/Mac.
	This interface has persisted both in the character-oriented MSDOS
	world and, in graphic form, in both the present-day Windows and
	Macintosh products.

FoxPro 2.0		1991	MSDOS
	This version of FoxPro should be mentioned separately from the
	1989 version because it is the first one that incorporated SQL and
	the Rushmore Technology.  The first versions of FoxPro basically
	incorporated the FoxBASE+ engine under the hood and it wasn't
	until FoxPro 2.0 that the full flowering of Fox's reputation for
	stellar performance occurred.

It might be noted in passing that FoxPro for Windows was essentially complete
at the time of Fox's acquisition by Microsoft in June of 1992 and was released
a few months later.

If other questions arise, I will try to help.  (I am more than moderately
familiar with both the history of FoxPro and its inner workings ... at least up
until 1994.)

Dave Fulton

FOXPRO PROFICIENCY QUESTIONS

     1. Versions of FoxPro. Name three major differences between 2.0 and
        2.5. [How long have they been around?]

     2. Language - Code a simple Foundation Read. Alternate: How do you get
        rid of the Command Window after you've put up a menu? [Are they
        still using DO WHILE?  Have they even _heard_ of a FR?]

     3. What is the difference between WHERE and HAVING? Describe how to
        implement an outer join in FoxPro. [A blank look here generates the
        prompt - "you know, in SQL" - which often leads to a "Oh, I only
        use FoxPro commands." And that's what I wanted to know .]

     4. Name five FoxPro third party products and what they do. [Do they
        insist on inventing everything themselves?]

     5. What periodicals do you regularly read? What books have you read?
        What else do you do to learn? [Do they understand the availability
        of resources available, or do they try to learn it all themselves?]

  6. Screen Builder. Describe the tradeoffs of desnippetizing. Where do
        you keep your code? Name two valid reasons for modifying the SPR
        [Ha! Trick question!]

     7. What's the difference between a function and a procedure? [Let's
        not forget the basics...]

     8. What does this line of code do: private all like j* [Are they
        familiar with safe programming techniques?]

     9. Describe your naming conventions for tables, fields, variables,
        arrays, windows. [A true mark of differentiation between hacks and
        professionals.]

    10. What technique do you use to integrate browses with READs. [The
        best answer here is "Ugh, I can hardly wait until they make it a
        true READ object..."]

 11. Name each band in the RW and describe when it is executed. [Are
        they still hand coding reports? Don't laugh - it happens....]

    12. Describe the Transport process. [We do a lot of xplat work - have
        they?]

    13. Write out a command to find a record that is Rushmore optimizable.
        Write one that is not. [Critical to find out if they understand how
        to take advantage of FoxPro's speed.]

    14. Describe an alternative to PACK, when you'd use the alternative,
        and why.  [Tells me if they've done any serious multi-user work.]

    15. Describe what Set Default and Set Path do. [These are fundamental
        concepts in our environment. A lot of programmers still just throw
        all the programs and tables in a single directory.]

    16. What's the difference between Build Project and Rebuild All. [Have
        they ever used the PM? And for what?']

 17. Tell me all you know about using Debug. [I _assume_ they've had
        bugs in their programs. Do they understand how to go about tracking
        them down efficiently?]

    Again, this isn't intended to be the ultimate FoxPro certification
    test.  The purpose is to weed out, over the phone, the amateurs from
    those who've a solid foundation of knowledge. I can deal with a few
    weak spots; gaping holes, on the other hand, well, I'll let them work
    for my competition.

FOXUSER FILE INVALID

From: mspitt@unity.ncsu.edu
Subject: Re: Message: Foxuser File is Invalid

Hi!
>
> HELP someone. This one is stumping even MS techies. I am trying to run a
> Foxpro app using the distribution kit. The app works fine in Fox but keeps
> generating problem messages using the .exe version. The last and most
> annoying one is 'Foxuser File is Invalid'. Tried 'Set Resource off' and
> re-copied the file to the app. Tried regenerating the file via Fox. Same
> message in the app. Any ideas?. Please! Thanks!

Are you on a network? If you are the Foxuser file needs to be read only. I
had the same problem and error message useing .exe files.

Mike
--
Michael Pitt
North Carolina State University
mspitt@eos.ncsu.edu

FTP FROM FOX

Date: Tue, 19 Dec 95 18:56:00 -0500
From: MIKE CASPAR <mcaspar@caspar.caspar.net>
Subject: RE: FTP transfers

FORWARDED MESSAGE from Evan E. Engstrom (EVAN$E @ SMTP
{evan_e@bit-by-bit.com}) at 12/19/95 2:21p

>  Reply-To: foxweb-l@dsw.com
>
>
>
>We maintain a corporate database from 12 satellite locations.  Updates flow
>in both directions to each location has an up to date copy to the corporate
>database. The current method of updates relies on 2 passes at each location
>using procomm and FPD2.5.
>
>We are installing a full connection to the Internet.  I'm looking for a
>solution to these updates using automatic FTP connections.  We have FPW2.6
>running company wide.  The file transfers will occur at approximately 1
>hour
>intervals during normal business hours.
>
>Any help will be appreciated.
***** NOTES from MIKE CASPAR (MCASPAR @ CASPAR) at 12/19/95 6:56p
I use connect2 routers and c2smtp/c2uucp combinations from infinite
technologies to do this automatically !

see http://www.infinite.ihub.com



###############################

Date: Tue, 12 Dec 1995 18:09:49 -0800 (PST)
From: HART@EUROPA.dnet.hac.com
Subject: Re: FW: Calling FTP from FoxPro

I have had success with the following method using the FTP that comes
in Novell LAN Workplace for DOS. I imagine you could substitute another
FTP since all are copies of the UNIX original.

Note that this is a "canned" file transfer--there is no user interaction
with FTP. It runs in the background, with an icon which appears on the
Windows desktop, and allows the FoxPro application to proceed in the
foreground.

To automate FTP, create a script containing the commands you would type
at the FTP> prompt:

open myhost
user myuserid mypassword
put myfile1
get hostfile1
quit

If the script needs to vary between transfers, write a .prg to write the
script.

You feed the script to FTP using input redirection:

C:\> ftp < myscript.txt

If you want the script to quit processing if an error occurs, add the
-x parameter:

C:\> ftp -x < myscript.txt

Get all this working from the DOS prompt before you add Windows or FoxPro.

If you try to RUN the above command from FoxPro, you will find that FoxPro
messes up the command line arguments & generally does not work.

So you create a batch file containing the following:

ftp -x < myscript.txt

Now you should be able to RUN the following from the command window:

run myftp.bat

If the DOS window does not close after the .bat file runs, use the PIF
editor on FoxRun.PIF. FoxRun.PIF is also the place to set aside more
memory for the run command should you find that necessary.

Now change your run command line to:

run /n7 myftp.bat

Note that control returns instantly to the foreground. Note further that
an icon appears on the desktop while the .bat file is running and quietly
disappears when the transfer is complete.

If you need confirmation that the transfer was successful, you could
redirect the ftp output to a file:

C:\> ftp -x < myscript.txt > myoutput.txt

FoxPro can fopen() myoutput.txt & sift through the output for the "XXX
bytes transmitted..." message(s).

Extra credit: I suspect that you could get rid of the .bat file by
creating a myftp.pif which passes the proper parameters to ftp. This
would also allow selection of an appropriate icon, caption, etc. Then:

run /n7 myftp.pif

That's the news from Lake Wobegon

-John Porter Hart
hart@sal.dnet.hac.com

-

GENGRAPH FRONTEND

Date: Sun, 29 Oct 1995 17:40:23 -0800
From: Rick Strahl <rstrahl@gorge.net>
Subject: Re: Graph Problems

>I think I found a bug in the runtime version of MS Graph (using FPW26). When
>I run gengraph.app from a cursor (my query results) the wizard runs fine, but
>when the graph is created, it is shown in a transparent fashion in the final
>wizard window, not in it's own window. Has anyone else encountered this
>problem and is there any way to solve it?
>

It's possible this is related to a bug in your video driver. Try running the
standard Windows display driver and see if the problem goes away.

Secondly, you might want to try to bypass the Wizard altogether and create
your graphs on the fly. I've written a PD front end application to GENGRAPH
that does just. You can grab it from:
http://www.west-wind.com/tech/wwfp2pd.htm ... This tool was also described
in an article in Febuary 95 FoxPro Advisor...


Regards,

+++ Rick ---

GENSCRN - ADDING @..GET/EDIT

 >Using foxpro for window 2.5 's screen painter, I cannot enter a default text
>in a so called 'edit region' (@...EDIT).  To do so, I have to add the
>'DEFAULT' clause to the @..EDIT-command in my generated code.
>
>Does anybody no how to enter default text within the screen painter?

Click on the MESSAGE box.  For the message, put

"" DEFAULT xxx
(Note the two leading quote marks).

You can also add things like NOEDIT this way.  Basically, anything in
the message box gets shoved into your .spr file at generation time.

*******

This is off the top of my head, but in general in the screen builder you
can add clauses to GETs by appending them on the MESSAGE snippet: for
exmaple,
"" DEFAULT "Default Text"
You can use this to add colours and other stuff too. Don't know whether
it'll still work in FP3 though 

GENXTAB - BUGS

  Lines 18               Bug in GENXTAB FPW 2.6 & 2.6a        No responses
derek.jubb@canrem.com              Derek Jubb at CRS Online  (Toronto, Ontario)

There are bugs in the processing of the row, col, and cell fields in the areas
of lines 250 and 350 of the program.

Specifically they are the lines which validate the data types, and the lines
which create the new database.

Replace the lines which read
   inpfields[1, x] with inpfields[m.rowfld, x]
   inpfields[2, x] with inpfields[m.colfld, x]
   inpfields[3, x] with inpfields[m.cellfld, x]

   where x is the secondary subscript.

Regards,

HELP COMPILER - PATCH

  > Does anyone know where to get a fix for the Help Compiler *hc31.exe) that
> shipped with FPW 2.6? This version does not support Word for Windows 6.0.
> The readme.txt file says it can be found at the microsoft developers
> forum, but I have been unable to find it. Thanks.
>
>
The latest version of the help compiler is HC505.EXE, a self-extracting
zip file.  You can get it from  ftp.microsoft.com  in the directory
softlib\mslfiles

HELP FUNCTION - CONTEXT SENSITIVE

Date:         Fri, 21 Jul 1995 11:03:29 CST
From: "Stephen Del Rea" <SREA@UAEX.ARKNET.EDU>
Subject:      FYI: Help Screen Function (was: Scrollable, read-only Ed)

I've added a help function to my app which uses F1 to display help on
a particular control in the current screen, or Shift-F1 to display help on
the screen itself.  It does a database lookup for the text to display
based on the current screen and control you are on at the time.  The
database has the fields combo, screen, field, and help, where combo
is blank for F1 or "S" to indicate help for Shift-F1, screen is the name
of the screen or "*" for all screens, field is the name of the field or "*"
for screen help, and help is a memo field containing the help text.

For the lookup, it tries to find an exact match for the screen and
control, or for all screens with this control variable (for screens with
the same control variable name), or for all screens with a
non-database-specific field name for this control variable (since, I
identify the database by the first two characters of the field name,
such as STLAT and WTLAT for the latitude values for the soil test and
water test databases).  Of course, you would want to modify this
showHelp routine to match your needs.

In the startup routine for the app (which is in the FARMMGMT.PRG
file), I have:

ON KEY LABEL F1 DO showHelp WITH WONTOP(), VARREAD(), " " ;
   IN FARMMGMT.PRG
ON KEY LABEL Shift-F1 DO showHelp WITH WONTOP(), VARREAD(), ;
   "S" IN FARMMGMT.PRG

The showHelp routine (in the FARMMGMT.PRG file) is as follows:

*------------------------------------------------------------------
*
* Procedure: showHelp
*
* Show the help message associated with the field if F1 is pressed or
* associated with the screen if Shift-F1 is pressed.
*
PROCEDURE showHelp
PARAMETERS winname,fieldname,keycombo
PRIVATE curdb
IF RDLEVEL() = 5
   ?? CHR(07)
   WAIT WINDOW "Too Many Screens Active (max 5) -  " + ;
      "Can't Display Help" TIMEOUT 5
   RETURN
ENDIF
curdb = ALIAS()
SELECT FarmHelp
GOTO TOP
* Find help for this screen or for this field in this screen.
IF keycombo = "S"
   LOCATE FOR (combo = keycombo) AND (SCREEN = winname) AND ;
      (FIELD = "*")
   IF EOF()
      ?? CHR(07)
      SELECT (curdb)
      RETURN
   ENDIF
ELSE
   LOCATE FOR (combo = keycombo) AND (SCREEN = winname) AND ;
      (FIELD = fieldname)
ENDIF
* If nothing is found for this field in this screen, see if there is help for
* this field in all (generic) screens instead
IF EOF()
   GOTO TOP
   LOCATE FOR (combo = keycombo) AND (SCREEN = "*") AND ;
      (FIELD = fieldname)
ENDIF
* If nothing is found for this field in generic screens, see if there is
* help for the corresponding non-database-specific field in all
* (generic) screens instead (the field name minus the first two
* database identifier characters)
IF EOF() AND (LEN(fieldname) > 2)
   GOTO TOP
   LOCATE FOR (combo = keycombo) AND (SCREEN = "*") AND ;
      (FIELD = SUBSTR(fieldname,3))
ENDIF
* If nothing is found for this field, see if there is help for this screen
* instead
IF EOF()
   GOTO TOP
   LOCATE FOR (combo = "S") AND (SCREEN = winname) AND ;
      (FIELD = "*")
ENDIF
* Display the help text in HELPSCRN.SPR and have F1 or Shift-F1 do
* the Close button hot key in HELPSCRN.SPR.
IF NOT EOF()
   PUSH KEY CLEAR
   ON KEY LABEL F1 KEYBOARD '{Alt-C}'
   ON KEY LABEL Shift-F1 KEYBOARD '{Alt-C}'
   DO HELPSCRN.SPR
   POP KEY
ELSE
   ?? CHR(07)
ENDIF
SELECT (curdb)
RETURN

HTML - CGI

Date: Fri, 28 Apr 95 16:25 PDT
From: randallg@wimsey.com (randall g)
Subject: Re: what people want to put on Web

>here's my situation:
>i have a foxpro program that gathers criteria from the user
>and then queries a database to get results; those results are
>then used for additional queries.
>i need to create an html page to gather criteria; the criteria
>is then used to perform a database query; a new html page would
>then be created containing the results of the query.
>i have an electronic ton of information about cgi, but i am
>still unsure about how to implement this - it seems that i need
>a cgi script that would pass parameters to a foxpro .exe that
>would in turn perform the query and return the results.  either
>foxpro or the cgi script would create the neccessary html page(s)
>on-the-fly.
>can foxpro perform the function of the cgi script, thereby
>bypassing the need to code in C or PERL?

Not really. The CGI method of data transfer has the Web Server process
calling an executable program for EACH web page hit or submission. Starting
up Foxpro in this way is going to take a long time. A more practical
solution is to have a small and fast C program which starts up, gathers the
user form input, starts a DDE link to fox (which is already running and is a
DDE server), POKE's the info, REQUEST's the result, and returns that to the
Web Server. I am currently working on such a thing to run under NT with
EMWAC's Web Server.


randall g   http://www.wimsey.com/~randallg

HTML PROJECT

Date: Tue, 11 Apr 1995 09:06:07 -0400
From: kjackson@lerc.nasa.gov (Keith Jackson)
Subject: Re: HTML & FoxPro

>On Sun, 9 Apr 1995 bwolfe@mail.lmi.org wrote:
>
>>      Is anyone out there creating HTML text from a FoxPro program?
>You may wish to check out this web address:
>
>http://www.state.sd.us/people/colink/fox_page.htm
>
>It includes a rteference to FOXHTML - a program for generating HTML from
>FOXPRO.  The author's name is listed and you could contact him.
>

I checked it out....  The author talks about what he wants to do and
concludes with:

More information forthcomming. The application is still very much in the
development phase. The primary obstacle is that there's not enough "time to
play".

I am in the same boat, so I have a proposal.  Who would be in favor of
making this an internet project.  Anyone is interested can join in.  First
we collect specs, propose an architecture, design the app, split it into
pieces (maybe the same task going to several people to compete for the best
solution), and present a product.

This product could cover everything from backending a form, to auto page
creation, to interacting with MS WORD's web browser.

Can you imagine the product we could turn out using all of our resources and
power of the net?  If you are interested, let me know via this mail list or
e-mail directly at kjackson@lerc.nasa.gov.

Keith

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Keith Jackson             \  phone: 216-977-1160                 .. __o
NYMA - SETAR              /  http://sven.lerc.nasa.gov/~vvkmj   .. -\<,
NASA Lewis Research Center\  email: kjackson@lerc.nasa.gov     ..(_)/(_)
~`~`~`~`~`~`~`~`

******************************************************
******************************************************

Date: Fri, 14 Apr 1995 05:31:47 -0400
From: davidk@cnct.com (David Kaufman)
Subject: Re: HTML - bottle the tools free, sell the apps!

Objectives are exactly the thing.  I cant see how we could create a single
commercial product through public channels.  We have I think imposed upon
ourselves the (dubious) honor and challenge of creating an open standard
such as HTML itself is.  We need to concentrate on methods, not
applications, per se.

For instance, I might want to use foxpro to store source text files, RTF
files, WORD, whatever, and other related source information (gifs &
whatnot). (BTW, I do) I want to be able to add to/maintain my information in
my word processor and use Fox and OLE to automatically, regenerate my HTML
files from changed, added, deleted "source" files.  then ftp those changes
to my remote HTML directory on a UNIX host.
I know I can automate the OLE importing files into it.  What I'd like to see
and contribute to the "public doamin" is the engine which will automatically
generate HTML files _FROM_ my source data through a HTML "rules" repository,
style templates, etc.  As we all know no Web page is an island.  The local
links and "detail" (linked documents) essentially "branch off" from a
starting point or home page and and this is the most tediuos chore of
maintaining the WEB for me, removing the refernece to this doc from any
other doc that links to it  when a doc is deleted or changed, renamed etc.
The more data you present, the more pages you need to prevent lengthy load
times, and the more hairy the maintenance becomes.

Someone else may be wanting to use Foxpro to read in an existing HTML and
say convert the tags to take advantage of the latest greatest Netscape
extensions.  Their app may be a file converter.

Another may want to use fox to steal (i mean download) thousands of pages
from all over the globe and create on-line forms-browsing search engines
like WAIS (although why reinvent a wheel?).

The point is we have to distill all of our pet projects (which we WILL
probably want market commercially on our own) down to the tools and, to use
an OO-ism, the METHODS we ALL will need for storing, retrieving, and
manipulating HTML "meta-data".

We all will need a common format for a "Rules" Repository which holds all
the languages-specific tags to a particular HTML-Language-version or set of
extensions.  This way when a new version comes out, the "FoxWebbers'
Consortium" (suggestions,on the name?) as a cooperative regenerates the
Rules repository, and places it in the Public Domain; we all have based our
apps on it so all we have to do is copy in the new repository and
(hopefully) it will run unchanged.  We just have to upgrade our apps to
_take_advanyage of new features (assuming, of course, the HTML spec
continues to be backward compatible, itself).

We will need (I will at least) a structure for importing an existing HTML
doc into a "database" (in the VFP3 sense of the word: maybe not a single
table) totally independant of the html tags & syntax.  In other words, a
tool should be able "parse" out the actual text, from the layout info,
font/size info, and Image info, and store all this "knowledge" such that the
file can then be intelligently/automatically processed *independant* and
reconstructed using a different "repository" - instant intelligent file
conversion from/to  RTF, TXT, new versions of html itself, what have you.
This I would guess will be the meat & potatoes.

But another handy tool would be a nice "live" feature-rich viewer.  FoxWin
has the graphics/sound/font/OLE support to be just as robust as Netscape
itself for browsing local files at least, and between general fields and
memo fields can go a step FARTHER than HTML itself by storing "locally
linked" binary sound & picture whatever files embedded permanently in the
same file.

Someone who likes Winnows OLE *A LOT* could develop a tool Using Foxpro's
and Netscapes Extemely extensive OLE communication support to say, I don't
know, have Fox tell netscape to check all my remote-links in the docs, to
make sure they are still valid.  Giving you a "hit-list" of possible bad
links before you even generate the final HTML.

I won't even touch on the new table support now in Netscape and the proposed
HTML 3.0 standard.  Yeah, I will.  Its outstandingly way cool, visually.
You can cause a "cell" to span multiple rows, and/or columns for visually
pleasing headers "Fat" cells, "tall" cells, cells with images in them, cells
with links of course, cells with whole other *tables* nested within them.
This reminds me of VFP3's "Grids" functions which I *cannot*wait* to get my
paws on :)

We could probably each spend months on any of these alone.  Our golden
opportunity is to each collaborate within a certain group our
interest/talent to produce logical, robust, extensible tools based on the
smae file structures.  If you don't know what application the tool may be
used in in the future, it will promote I think a more robust design AND
prevent propietary solutions that do the job for MY purpose, but require you
to reinvent the internal combustion engine for yours.  Since these would be
placed in the public domain, any one would be free to extend them for their
own purposes or even hack them to death.  But it would be in our own best
interests to, if we desire changes, to propose them to the standards
"committee" or group, so that as we all get rich selling HTML apps, we know
our apps will be compatible with one another, a necessary consideration on
the WWW.

1st: Each group must decide on the demands and requirements for their tool
and publish this to the whole group.  While VFP is not yet available we can
take a clue by making our tools each a combination of data AND the the
methods and functions necessary to manipulate the data.  If I as a user of
the tool have to code my own ways of updating say the title of an HTML doc
in a dbf, although this may be easily done. the tool should provide this
functionality as a UDF call.  In VFP3 the database "container" will be
insisting on these access constraints and rightly so. This will provide some
consistency in all of our final products and users will be assured of
certain functionality by virtue of the fact that this is based on our open
standards tools.

By the Way count me in! :) This is my first post to the group.  I'm a self
underemployed FPW2.5b programmer in the New York Metro area.  I've only been
using FoxPro for about a year now, before that I developed a lot in C++ but
not professionally.

Looking for paying work but in the meantime willing to devotesome time to
this project!

Accepting any/all refferals (and flames!),

David Kaufman  [davidk@cnct.com]
Resource Services
Bayonne, New Jersey  07002