Foundation Read vs. READ EVENTS

[Scott24x7]

I've been converting applications from 2.6 to VFP recently, and in the review of my previous design, I've been reading alot about READ EVENTS. I'm still using a foundation READ, which I understand in VFP now gives me 10 reads instead of 5, which is somewhat helpful, but I'd like to "Make the leap" as it were, to the bigger perspective of no longer being concerened with READ clauses anymore... that brings me to two questions. First, this is how I used to establish my foundation READ, and set up my environment:

IF NOT M.glQUITAPP
*
DEFINE WINDOW BACKGRND FROM 0,0 TO 120,340
FONT 'TimesNewRoman', 10 FILL
FILE GRAPHICS\OPENLOGO.BMP IN SCREEN
SHOW WINDOW BACKGRND

* Call root menu of application, and establish the
* Foundation read below.

DO MAINMENU.MPR
DO MENUINFO
*
DO SPLASH.SPR
=INKEY(4,'HM')
*
READ VALID M.glQUITAPP
ENDIF

This would creat a background for my application, display an image in the background, show a splash screen (for 4 seconds), then establish the application's foundation read.

Then, every screen thereafter, I would issue a "READ MODAL" clause on to ensure they don't get "LOST" behind the graphic of my screen.

I've seen some things on "MDI" forms. I don't understand them, or how to implment them. What is the advantage/disadvantage of them? Is it something I should use here?

Also, How, with a READ EVENTS do I manage the creation/distruction of other screens??? For instance, I have an error routine that captures syntax errors, and displays a window to "Retry, Cancel, or Quit". I currently control it with:

READ CYCLE OBJECT 3 MODAL

But that keeps blowing up on me when some types of errors occur. How would I change this to support READ EVENTS?

Thanks,
-Scott

 

[ChrisRChamberlain]

Scott

The good news is that READ EVENTS etc is relatively simple to implement in comparision to a foundation READ.

See Thread184-42735, Thread184-24450

For an idea on a splash screen, see Thread184-134392

For simplicity's sake, you can consider there to be two types of window, MDI, the default, ie windows that are bounded by the VFP application, and top-level forms, SDI, that are bounded by the screen.

You can mix the two in a VFP application, and can also consider the _SCREEN object to be a form, if you place a form in it, removing the form's titlebar and border and size the form to be that of the _SCREEN object, (this will simulate a top-level screen).

To answer your question as to which to use, I would stay with the default MDI type until such time as you actually need the features of a top-level form.

You will probably need to rebuild your error trapping routine, creating either a new form method, (recommended), or procedure.

It is important to create an object reference to any form you call by DO FORM main NAME oMain LINKED.

You can then use the object reference to access the form's error trapping routine by:-

ON ERROR oMain.mErrorTrap()

This enables you to have one routine for the whole application - alternatively you can use the error event of an individual object or control, or mix n' match to suit.

Equally you can access any property/method of any form by...

oMain.mPrintReport([myreport.frx])

...where myreport.frx is a parameter passed to the method .mPrintReport()

Depending on how this thread develops, you may want to isolate some of these topics and start new threads.

HTH

Chris