Edit (Find/Find Again) 
Author Message
 Edit (Find/Find Again)

Is there any way to use the foxpro Find commands in your own
program (the ones that pop up when you hit CTRL-F) without
including them in your menu.

basically, i want an ON KEY LABEL CTRL+F DO FIND or whatever



Mon, 10 Feb 1997 02:07:43 GMT  
 Edit (Find/Find Again)


>Is there any way to use the foxpro Find commands in your own
>program (the ones that pop up when you hit CTRL-F) without
>including them in your menu.

>basically, i want an ON KEY LABEL CTRL+F DO FIND or whatever

Sure. Any FoxPro bar function can be put into your program as follows:

Define a popup.  Define a bar for that popup with number _ME_FIND or
whatever (you can create a quick menu to find out the number) and KEY
whatever you want to activate the function.  Once the bar is defined, the
function is available (as long as SYSMENU is AUTO or ON). The popup
doesn't even have to be activated (visible).

I use this method for all my special keystroke actions instead of ON KEY
LABEL, since it groups them so nicely.

Hope this helps,

Mon, 10 Feb 1997 13:12:17 GMT  
 Edit (Find/Find Again)


> Is there any way to use the foxpro Find commands in your own program (the

ones that pop up when you hit CTRL-F) without including them in your menu.
basically, i want an ON KEY LABEL CTRL+F DO FIND or whatever

Evan Simpson replied with the suggestion that a popup be defined
with number _MED_FIND or whatever. This works well if you have SYSMENU set
to AUTO or ON. In many of my screens, I have SET SYSMENU OFF, to prevent
other menu options from being selected - too many options to include
SKIPS for all of them in the Menu Builder.

Does anyone know of a way that find, replace, cut, copy and paste (in
particular) can be used in an app when SYSMENU is SET OFF?

Any suggestions are appreciated.

Tue, 11 Feb 1997 12:12:12 GMT  
 Edit (Find/Find Again)

(Kevin Johnson) writes:
>In the past day, I've learned an important lesson about Rushmore
>and networks: if Rushmore doesn't kick in on a remote SQL-Select,
>the performance penalty is multiplied by much more than I would
>have expected.

I think your experience reveals an important aspect of the foxpro query
engine that pertains to networked (file server) environments:

During a Rushmore-optomizable query, Foxpro first requests the *index*
from the file server. Since the index is *much* smaller than the actual
.DBF file, the transfer is very fast. With the index now in RAM memory on
the workstation, foxpro can calculate the exact disk address (of the file
server's hard drive) where the desired records reside. Foxpro then
requests from the server only those specific disk-address blocks needed to
answer the (optimizable) query. Again, the transfer is *very* fast because
the network transfer is minimal.

Even though Foxpro is *not* client server, it can make of use of its index
scheme to retrieve only the physical disk address needed to answer a query
-- if the query is optimizable.

In contrast, non-optomizable queries require Foxpro to read the whole .DBF
file, which, in a file server environment, requires that the whole .DBF
file be sent over the network cable.

Understanding this distinction is crucial to exploiting the Rushmore


Thu, 13 Feb 1997 14:44:02 GMT  
 Edit (Find/Find Again)

More experience with Rushmore... it doesn't always work depending on the
capabilities of the machine.  For example a 386SX with only 1 meg of RAM
will likely not use Rushmore because it has insufficient memory for some
of the query type commands.

I'm not saying that it won't work; just that my experience has been that
on lower end machines you may or may not get Rushmore operational, and
not necessarily on all optimizable commands.

Since I distribute applications to a number of clients using different
hardware (all IBM-based) I can't be guaranteed of Rushmore performance on
all machines... whenever possible, then, I'll simulate Rushmore with
other commands - for instance (with an index on account number and an
index on permit number)

   LOCATE FOR account=anumber AND permit=pnumber

With Rushmore working this is fast.  With Rushmore not working this is
agonizingly slow.  So instead I'll just use something that works in both

   SET ORDER TO anumber
   SEEK anumber
   LOCATE FOR permit=pnumber WHILE account=anumber

With or without Rushmore this routine works quite quickly and without
the worry of whether the hardware is capable of supporting Rushmore.

On the flip-side, though, there are times when Rushmore is worth it's
weight in gold... these are cases where it's difficult to simulate
Rushmore, or when it's not feasible.  Such an example is the SELECT
command... it's far faster to SELECT TO CURSOR WHERE (expr) and run a
report than it is to just REPORT FORM FOR (expr).

Anyway, that's my $0.02... I'd be curious to see what other workarounds
people have come up with to solve access speed problems on relatively
large databases.


-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
Blake Laufer                                    Hamilton, Ontario, Canada
Logic Innovations (Inc.)                                   (905) 389-6698

Thu, 13 Feb 1997 21:59:59 GMT  
 [ 5 post ] 

 Relevant Pages 

1. Using Find and Find Again

2. Edit Find in grids

3. Using the Edit|Find menu option

4. Do while found--- what if not found?

5. VFP 5.0 Using EDIT/FIND from menu bar to search for a date

6. FOUND VFP5.0 GRID BUG - Column not found error

7. How Can I Edit the "Find"?

8. Finding Cursor on Edit

9. USE AGAIN is at it again

10. Not a table: Once and again (and again)

11. Cnnot find f:\foxprow\foxprow.exe error message

12. Where can I find COMCTL1.HLP?


Powered by phpBB® Forum Software