Codebook 2.6 - the foundation read and event handler

Codebook 2.6 - the foundation read and event handler

Post by Steven J. Browne » Thu, 08 Dec 1994 00:47:11



1st question: (foundation read)

I need some explination concerning the discussion in Codebook 2.6 about the
foundation read.

Example code given:
   IF glEndProg
        RETURN .T.
   ENDIF

The book, in my reading, implies that this snippet is a test performed when
the "quit application" part of a program is executed from the menu.  But
doesn't the procedure or command for the menu item have to set glEndProg to
.T. first? And if so where does this example get placed in the program? in
the menu's cleanup code?

If this snippet goes in the cleanup code, is it still necessary to use the
"CLEAR READ ALL" (as recommended by the Microsoft manuals in their
discussion of the foundation read)?

******************************************************************************
2nd question: (event loop - menu option)

Similarly to the first question, where does the code snippet concerning
gcNextProg actually get placed? in the menu item procedure snippet or
somewhere else?

******************************************************************************
3rd question: (more general)

The style guide on given on names for variables doesn't say much about the
"m." prefix given to variables.  I know that it is not always necessary to
use this prefix, but sometimes it is.  Is there a style suggestion for using
this?

  Steve Brownell     **  My opinions are my own, which is a good thing.  **  

  Dow Chemical Co.   **  them.                                           **

 
 
 

Codebook 2.6 - the foundation read and event handler

Post by Menachem Bazian, C » Fri, 09 Dec 1994 20:04:39




Hi Steve!

I will try to address your questions one at a time...

Quote:> 1st question: (foundation read)

> I need some explination concerning the discussion in Codebook 2.6 about the
> foundation read.

> Example code given:
>    IF glEndProg
>         RETURN .T.
>    ENDIF

> The book, in my reading, implies that this snippet is a test performed when
> the "quit application" part of a program is executed from the menu.  But
> doesn't the procedure or command for the menu item have to set glEndProg to
> .T. first? And if so where does this example get placed in the program? in
> the menu's cleanup code?

> If this snippet goes in the cleanup code, is it still necessary to use the
> "CLEAR READ ALL" (as recommended by the Microsoft manuals in their
> discussion of the foundation read)?

In procedure mExit which is in the menu cleanup, the code sets glEndProg to
.T. and then issues a CLEAR READ ALL. This has the effect of closing all
active READs which would then throw the program back to the foundation read.
That's why this test is up front.

Quote:

> ******************************************************************************
> 2nd question: (event loop - menu option)

> Similarly to the first question, where does the code snippet concerning
> gcNextProg actually get placed? in the menu item procedure snippet or
> somewhere else?

gcNextProg is set in the procedure mHit which is also in the menu cleanup.
When you select a READ window, you are executing the .SPR in the following
manner:

DO mhit IN main.mpr WITH "CD.SPR"

mHit checks for an active read (by checking RDLEVEL() and, if a read is in
effect (RDLEVEL() will be greater than 1 if a read other than the foundation
read is in effect) it sets gcNexProg to the name of the .SPR to run and then
issues a CLEAR READ to close the current read.

Quote:

> ******************************************************************************
> 3rd question: (more general)

> The style guide on given on names for variables doesn't say much about the
> "m." prefix given to variables.  I know that it is not always necessary to
> use this prefix, but sometimes it is.  Is there a style suggestion for using
> this?

You've touched upon a minor religious war between myself and someone else
in the office. Here's the basic idea.

You *must* use m. when dealing with memvars that are dupes of fields.

e.g.

    m.Cid   vs. CD.Cid

Technically, it is optional for other variables. Here's where the disagreement
kinda comes in. One view says *always use m. so it's clear*. Another says
that variables names l*, g*, t*, j*, etc are clearly memvars so it is
clear in and of itself.

Take your pick <g>.

Personally, I try to put in m. whenever I remember with other variables.
I *always* use it when dealing with field duplicate memvars.

Hope this helps!

Menachem

+---------------------------------+--------------------------+


| 1060 Main St. River Edge, NJ    | 201-489-2500             |
+---------------------------------+--------------------------+
| Home of GENSCRNX, The FOXPRO Codebook 2.6 and the highly   |
| acclaimed Flash Training Courses!                          |
+------------------------------------------------------------+

 
 
 

1. HELP! Foundation Read Event Handler

I am relatively new at developing with FoxPro and have FoxPro 2.6a for the
Mac.  I was wondering if someone would help me with something I've been
struggling with.
I've been trying to make a foundation read that would coordinate menu and
screen events and have gone over and over the examples in the chapter
"Coordinating Screens and Menus" in the Developer's Guide, but in the
example they use a "Control" window which I do not use and it (and maybe
others things) is confusing me.  All I want to do is make it so that a
user can pick Screen A from the menu, then without closing Screen A pick
Screen B from the menu, and so on.  Then the user could click back and
forth between the screens, entering data as he pleased.  When a user
picked a screen from the menu and it was already there, it would become
the active screen.  And if the user moved a screen, as long as it wasn't
closed, whenever he clicked on it again it would stay where he moved it
and not jump back to where it is initially defined at.
I would really appreciate some help on this.  Much thankyou's in advance.

Cannon Smith

P.S.  Though I can't afford it for a few months, I am also wondering if
Visual FoxPro makes this event handling any easier???  Thanks again.

--
Cannon and Nicole Smith
P.O. Box 65
Hill Spring, AB Canada
TOK 1EO

2. DBPROCESS dead from BCP

3. FPM 2.6 Foundation READ needs mouseClick?

4. SQL 7.0 "shrink database" not doing anything.

5. timeout in a FPW 2.6 foundation read?

6. class name in target list

7. FPM 2.6 Foundation reads and a toolbar

8. IL - Chicago - Oracle Financials Consultant

9. Foundation Read and re-cycle reads...

10. Codebook Error handlers

11. Codebook 2.6 sample code

12. Where is the source code for foxpro 2.6 codebook by Y A Griver

13. FPW2.6 and FP Codebook 2.6 (YAG) want contacts