When to use read events 1

[Judi201]

Hi!

I decided that I could see no need for a menu in the program I am rewriting from old dos FP to VFP 6.0 so I am trying to use a main form as my startup. If anyone has reasons not to do this I would appreciate hearing them.

I created a MAIN.PRG with SET ,DEFAULT, PATH, etc.
Then DO FORM MyMainForm follow by READ EVENTS

When I run MAIN.PRG, the FORM MyMainForm is not displayed.
If I step through it in debug it is displayed!!! Why??

I removed the READ EVENTS and it runs from the MAIN.PRG.

I was using craigsboyd's answer in thread #1085137 as a guide in looking for the solution and tried another form, a top level form, so I am thinking that I have set something somewhere that is causing the behavior.

Would someone please explain the use of a Top Level form and is that the form that you want to be the first displayed or an additional form.

As I said, the form loads without the READ EVENTS but it will not call other forms as I need it to do.

ANY help will be appreciated.

Judi

 

[alvechurchdata]

it will not call other forms as I need it to do.

Do you have the other forms set as "In Top-level form"?

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[TamarGranor]

Sounds more like it's running and disappearing than not running at all. Is there anything in the form that would cause it to shut down immediately?

Tamar

 

[Olaf Doschke]

Hi Judi,

Top Level form would be the main form. But Top Level Forms and In Top Level Forms also need other settings to be correct, eg desktop = .t. for being put inside desktop instead of _screen.

And as you want an app with one main form and several sub forms, you should not use the Top Level form approach, as subforms are clipped by the area of the top level form (I think). What you may want is no visible screen (the window holding the main menu you don't need). Then simply set _screen.visible = .f. at start.

READ EVENTS is not neccessary if the main form is a modal form, that is WindowType = 1. If the form is nonmodal the READ EVENTS is needed to prevent the application from quitting, because then after the Activate()-Event of the form the program continues after DO FORM and if there is no additional code (like READ EVENTS) quits. If the main form is modal the program will only return to the line after DO FORM myMainForm when you exit the form.

Another thing is: Where did you put CLEAR EVENTS? If you put READ EVENTS in your code, you also need a CLEAR EVENTS to return to the code after READ EVENTS. If you put that in the Activate the form would disappear of course. CLEAR EVENTS should be done in Unload or Destroy of such a main form.

Bye, Olaf.

 

[Judi201]

Thanks All,

I quickly found the problem when I checked to see if my main form was modal and discovered that ShowWindow was set to 1 (left over from my playing with the Top Form idea. I changed that to 0, Window Type was modeless as I intended. It works as expected now.

So my situation is:

MAIN.PRG with SET, DEFAULT, PATH, etc. (Is this where I set the _Screen.Visible = .F. ?)
DO FORM MyMainForm
READ EVENTS

I have CLEAR EVENTS in Destroy of MyMainForm

Is this a 'preferred' way of doing things? Any comments will be appreciated.

The other forms I am using are modal (to set up reports and such))
All actual work is done on MyMainForm (pageframe with 6 pages)

Would someone suggest the best approach for SHUTDOWN?

Thank you all for the help.

Judi

 

[Olaf Doschke]

Hi Judi,

the way you work with READ/CLEAR EVENTS sounds very good.
The best way for SHUTDOWN may be the simplest way of handling this: ON SHUTDOWN QUIT. QUIT is a hard way to exit and you may loose last changed data, but it's quite painless and prevents the message "foxpro cannot quit now".

Bye, Olaf.

 

[Judi201]

Olaf,
Thanks for the comment, but I would rather not lose data if possible . I will think on that more down the road.

Judi

 

[Mike Lewis]

I disagree with using ON SHUTDOWN QUIT. The Shutdown handler has do more than blindly quitting the application.

At the very least, it should do a CLEAR EVENTS, just in case it was called from within the event loop. Also, it will probably need to handle a situation where it is called while a modal form is active.

Another problem occurs if the Shutdown handler issues QUIT, but the active form has code in its Destroy or Unload that interferes with the shutdown process (for example, if the form contains unsaved edits).

For all these reasons, ON SHUTDOWN should call a procedure that cleanly closes the application. For example, it should loop through all the open forms, trying to close them while dealing with unsaved edits.

One further argument against ON SHUTDOWN QUIT: It's very annoying when this fires during testing, as it wil close the entire VFP development environment.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)

 

[Judi201]

Mike,

Thanks for the response. I think those are the issues I was seeking comments on. However, those are issues that can wait for now I just close the form with my exit and remain in VFP. I wanted the startup to work because without it I did not have paths set and etc. I have a long way to go before delivery on this project!

I will explore what I can find on SHUTDOWN and return if I need help.

Thanks for all.

Judi

 

[Mike Lewis]

Judi,

those are issues that can wait for now

Yes, I think that's right. You're right to focus on the forms and the pathing issues.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)

 

[TomLeMes]

Maybe this should go in a new thread but at least posting here shows that I have bothered to read around this subject a bit.

I have a startup prog like this:

ON SHUTDOWN do ShutdownProc in .\progs\shutdn
* some setup stuff here - set path etc... 
_Screen.visible = .F.

DO FORM .\forms\MF_login
READ events
ON SHUTDOWN

As you can see, I have created a shutdown procedure and have a READ EVENTS. I call a login form where user enters details and then a main form is called. This form calls other forms and all seems to be going OK.

EXCEPT, that now I have a form that uses a toolbar. I've created a custom toolbar class and in the INIT code of my form I use the following to create the toolbar and dock it:

objTool = CREATEOBJECT('toolbar_main')
objTool.visible = .t.
objTool.dock(0)
objTool.movable = .f.
MESSAGEBOX('toolbar installed')

This all goes well - the toolbar is created and docks where I want it, until I click OK on the msgbox, at which point the toolbar disappears. It's just like when you don't have a READ EVENTS, but I thought that the original READ EVENTS I had in my startup code would take care of that. All my forms are set to be Top Level Forms and the toolbar is set to show in top level form. Can anyone explain this to me?

Tom

 

[Mike Lewis]

Tom,

At which point in the process are you instantiating the toolbar? Is it before or after the form?

Also, when you say the toolbar disappears, does the app close down at that point, or does the form still run?

I'd also suggest that, to help isolate the problem, you comment out the line that makes _SCREEN invisible. That will make trouble-shooting easier. You can always re-instate it later.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)

 

[TomLeMes]

Sorry, hopefully this will make it a bit clearer. I have a Menu Form and a User Form. The Menu Form calls the User Form using

DO FORM .\forms\MD_user

The User Form is the one that I want to have the toolbar. The code that instantiates the toolbar is in the INIT event of the User Form.

What actually happens is that the toolbar appears on the Menu Form! As soon as I click OK to the messagebox (see code in my previous post) the toolbar disappears from the Menu Form and then the User Form shows up (without any toolbar)!

This was my original situation. So I also copied the toolbar instantiation code and put it in the click event of a button on the User Form so that I could try re-running it once the form was well and truly there. The same behaviour occurs:

The toolbar appears and docks (this time to the User Form). The messagebox pops up. I click OK to the msgbox. The toolbar disappears, leaving the form running otherwise normally.

 

[TomLeMes]

Very strange. I've stripped this down to the bare essentials in an attempt to get a very simple example that works. Then at least I could start to introduce some of the other variables (adding it into my ongoing project environment etc.) and see at what point it stops working.

I've created a brand new project with a single program and a single form. The form has a single button which should add and dock a simple toolbar. The program code is:

SET DEFAULT TO "Q:\_VSS Working Folders\myProj"
SET CLASSLIB TO .\libs\_myproj.vcx
DO FORM .\forms\testform
READ events

My form is set to be Top-Level and Modal. The code on the click event of the button is:

objTool = CREATEOBJECT('ToolBar_main')
objTool.visible = .t.
thisform.Activate 
objTool.dock(0)
objTool.movable = .f.
MESSAGEBOX('toolbar installed')

'Toolbar_main' is the name of the toolbar I've subclassed from the baseclass toolbar. It contains a couple of standard buttons.

Now I think I must be missing something obvious here because I still get the same behaviour - I click the button, the toolbar appears and docks, the messagebox pops up, then as soon as I click OK, the toolbar disappears.

I've just put a messagebox in the destroy event of the toolbar and it is indeed being destroyed as soon as I click OK to the original ("toolbar installed") msgbox. Is there anything that could cause a toolbar to be immediately destroyed like that? Can anyone provide me with a simple example that works to compare against?

 

[Mike Lewis]

Tom,

I think the problem is that you are storing the object reference to the toolbar in a variable (objTool), but that variable is local to the click event of the button. When the click event exists, the variable goes out of scope and the toolbar is destroyed.

To solve it, try making objTool a custom property of the form. Then, in the click event, refer to it as THISFORM.objTool. For example

THISFORM.objTool = CREATEOBJECT('ToolBar_main')

Perhaps you could try that and see what difference it makes.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)

 

[TomLeMes]

Thanks Mike - that did the trick. I hadn't thought of that but it works perfectly - thanks very much for your help,

Tom

 

[Mike Lewis]

Tom,

Glad it works.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)

 

[Olaf Doschke]

Hi Mike,

regarding ON SHUTDOWN QUIT:

a) QUIT exits even if a modal form runs or READ EVENTS got no CLEAR EVENTS or any DESTROY event. QUIT is a hard exit.

b) non saved changes to data may be a reason, but you can't prevent a computer shutdown caused by the user pressing OFF for 3 seconds or simply pulling the power plug. Any routine I've written to warn users of lost changes (prevent exit if data could be lost) or take care of modal dialogs etc (force exit if user has left computer and application should shutdown for maintainance reasons) have been an annoyance to users or didn't work in all situations. QUIT does work.

If the IDE shutdown is an issue for you, you may do

if _vfp.startmode>1
   on shutdown quit
else
   on shutdown cancel && or clear events, whatever suits you
endif

Bye, Olaf.

 

[Mike Lewis]

Hi Olaf,

QUIT exits even if a modal form runs or READ EVENTS got no CLEAR EVENTS or any DESTROY event. QUIT is a hard exit.

Are you sure about that? I've seen situations where there is a modal form active, and the error-handler issues a QUIT. The user then sees the "Cannot quit Visual Foxpro" message. When he eventually closes the modal form, the application exists.

Similarly with a QUIT issued when READ EVENTS is active. That's way the shutdown handler would normally issue CLEAR EVENTS.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)

 

[Judi201]

Hi!
It is interesting to see what my question has triggered. I decided to not worry about SHUTDOWN for now, but my mind wouldn't let go so I searched this forum and others for comments and I realize that was not a question for a simple 1-2-3 answer. Again I realize how you pros must smile at some of our questions (thinking Oh, but there is more to it than that). I read everything and learn so much. It is better than any class. If I don't need it now, I most likely will someday. Thanks so much to all of you who answer.

Judi