We are having problems with users crashing out of OI menus.

It seems to occur with new users who tend to 'dither' over menu items trying to make up their mind what to click on.

In the worst cases it is occuring up to 10 times a day.

We are using OI 3.6.1. The crash takes users back to Win 95/98.

It occurs on stand-alone PCs and networks.

Any ideas on how to over-come this?

Jane

Not sure why this would be specifically on menus but do you have anything running in IDLEPROC that may be causing the crash when it kicks in ?

Tony

Hi Jane,

Please post the error message or GPF details or debugger error or whatever the crash is. Also, any relevant details like timers, idleprocs, helptext on the menus, is the menu on a dialog box or mdi frame or mdi child or regular non-modal window, etc.

Cameron Purdy

Revelation Software

Its not a 'crash' in the sense that we get no error messages. OI simple 'closes down' and goes back to the desktop. No, we are not using an IDLEPROC - don't even know what one is…

Jane

Jane

If you can duplicate this as you said it occurs 10+ times per day then I suggest opening up the system monitor and watching to see what happens when the cursor is moved over the menu bar. May need some sort of debug in close to stop OI shutting the application before you have a chance to review the event chain.

Tony

You describe it as crashing. Is there a chance that it could be logging you out for inactivity? Is the software author/ess contactable?

amcauley@sprezzatura.com

Sprezzatura Group

World Leaders in all things RevSoft

Thanks for the response. Everyone else seems to have gone quiet.

I've never used the monitor before, but I suspect your cunning plan may be a little tricky. Like where would you put a debug when waiting for a menu item to be chosen?

Any thoughts?

Jane

The System Monitor is a very useful tool which performs many functions. One of which is to view the event chain. To open the monitor you need to be in development mode then choose Tools, Advanced, System Monitor. The monitor screen will open.

You will notice in the bottom part of the screen that as you move around OI and/or your application the actual events that are occuring (and those that aren't ! - more of that later) appear to whizz past. Try running one of your windows and you will see the event chain, then click a button and you will see the system running the CLICK event code. By resizing the window and clearing the text (simple cut and paste controls) you can get the monitor to be visible as you run your application.

OK now you are familar with how system monitor works. My suggestion to see why your system appears to be closing down was as follows. If you place a DEBUG statement in the CLOSE event of the main MDI frame window then whenever that window closes the system will stop and drop to the debugger. This will give you the opportunity to examine both the debugger and system monitor. By looking back in the event chain you MAY be able to see the sequence of events that caused the window to close.

Be aware that by placing any script in the CLOSE event of the window you are getting in the way of OIs own system event handlers so you need to either change RETURN 0 to RETURN 1 or use the Forward_Event() subroutine to allow the system to actually close the window. Without this you could be in a catch 22 of never being able to close the window.

This method of debugging can be applied anywhere. It may not solve the problem but at least you can see what is occuring just before the window closes.

Hope this helps.

Tony

Thanks Tony. I feel like I actually have a sensible plan of attack now. I'll post anything I find out.

View this thread on the forum...