Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Issuing a CLEAR EVENTS from an error routine? 2

Status
Not open for further replies.
Oct 21, 2002
22
US
Hello peeps...

I am trying to issue a CLEAR EVENTS from an error routine called from ON ERROR. The error routine is contained in my main.prg which called the original form that has thrown the error. In the error routine I issue a CLEAR EVENTS (for the original form) then call my error form and finally do a READ EVENTS. Everything works as expected except that my error form immediately shuts down and the app closes.


This leads me to believe that the CLEAR EVENTS is not in fact working. Am I calling the CLEAR EVENTS in the wrong place and if so, where should I be calling it?

Oh...all forms are modal and as Top-Level forms.



Sample code....

On Error Do ErrorScreen

DO FORM splash
READ events
DO FORM main
READ EVENTS


Procedure ErrorScreen
CLEAR EVENTS
Do Form ErrorScreen
READ EVENTS
Return
 
Why have you got CLEAR EVENTS and READ EVENTS around your DO FORM? It doesn't look right. In general, you only need one READ EVENTS in the entire application, in the main program. You can then put CLEAR EVENTS in whatever place the user signals they want to quit, such as in the Exit command in a menu.

If you want a given form (any form in the application) to pause and trap events, you need to make it modal.

I suggest you take a look at your READ EVENTS and CLEAR EVENTS first. Once you've got those right, you can turn your attention to the error routine.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business
 
Thank you for replying Mike. :)

I have three forms...Splash, Main and ErrorScreen. All are modal and Show as Top-Level forms. On the Unload methods I have CLEAR EVENTS. If I do not issue a READ EVENTS after calling my splash form the main form will try to load before I have completed the work I was doing in the splash form.

Is that not the expected behavior?
 
The problem is that top-level forms can't be modal. That's why you're seeing what you're seeing with the main form loading before the splash disappears.

I think you have a couple of options. For sure, I'd make the error handler form In top-level rather than top-level itself. Then it'll be controlled by the main form's READ EVENTS.

You could also let the main form come up first and put the splash form in it.

Tamar
 
Gweniviere,

Not only can't a top-level form be modal, but -- if you think about it -- you wouldn't want it to be modal. In fact, does modality really mean anything in the context of a single form in isolation?

Anyway, philosophy aside ..... By all means, put a READ EVENTS before the splash screen. When the splash screen has finished doing whatever it does, have it issue CLEAR EVENTS. (It might need to do this from a timer, if the screen has to stay alive for a given period.)

Then, in your main program, issue READ EVENTS immediately after you have displayed your main interface (that is, the top-level menu or the main form; if it's a form, it shouldn't be modal).

Again, issue CLEAR EVENTS from the part of your interface used to close down the app, such as a Quit button. Remember, the CLEAR EVENTS will transfer control to the line after the most recent READ EVENTS, so that's where you want your clean-up code (including, by the way, a command to cancel the ON ERROR).

As far as the error-handler itself is concerned, if you must use a form for that, make it a normal modal form (not top-level). As its modal, it won't need its own READ EVENTS. When the user is ready to dismiss the form, issue CLEAR EVENTS. (You can make the whole thing a bit simpler by using a messagebox rather than a form in the error handler, but you will still need CLEAR EVENTS otherwise the eventual QUIT command will fail.)

Hope this makes sense.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business
 
Tamar and Mike,

Thank you both the help. I think I have a better understanding of what is going on now. I still have not figured out a way to do what I want to do, but at least now I know I was headed down the wrong path. :)

Thanks again.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top