We have a couple if instances on different workstations (within our company,and onl client PCs) where OI 8.0.8, is not responding, or crashing, or both, on Windows 7.

To make it slightly more awkward, we also use some SRP controls within our forms, so it is unclear at this stage whether it is OI or not.

Does anyone have any simliar experiences.

If so, any suggestions as to what might be the cause, or where to look.

Colin

I am using 9.3.1 on Windows 7 64-bit.

What kind of crash are you seeing?

Jim R Vaughan

www.waterloo-software.com

I would check to see what DEP is set to. Also, is the OS 32 bit or 64?

Check the windows application event log for entries corresponding to when the program crashes. You should be able to determine what module the program fault occurs in. This information will help shed some light where the problem is occurring.

Does the program crash immediately or crash after being unresponsive for a period of time?

OpenInsight 9.x is recommended for Windows 7 and 64bit environments because it is DEP compatible. Be sure to turn DEP completely off and disable the application experience lookup service if it is running.

If you are running a process in OI (8) that doesn't yield to Windows, then Windows can interpret this as 'Not Responding' - even though the CPU% in Task Manager shows that OINSIGHT.EXE is busy doing something. So in this instance, 'Not Responding' doesn't mean that OI has crashed!

In Windows 7, this is exacerbated by the application window being disabled - ie going grey and unresponsive to user input. So if you're process has a Cancel button, you can't push it!

We found the easiest solution in Windows 7 is to set the application to run in Windows XP (SP3) Compatibility mode. This can be done on the Compatibility tab of the shortcut Properties page.

We have some SRP controls too. One problem we've found is the redrawing of editbox borders and scrollbars. This seems to be alleviated by setting the Disable Desktop Composition compatibility setting .

HTH, M@

[img]http://www.vernonsystems.com/images/logo_main_ani.gif[/img]

Thanks guys

The behaviour seems to follow, ie it goes grey and unresponsive.

Certainly seems like a yield issue, and W7 decides its had enough, but too soon.

I will make the changes suggested and see.

Colin

I've just discovered that an application can disable this behaviour (ie going grey and unresponsive) by calling the DisableProcessWindowsGhosting() Windows API function on startup. This "Disables the window ghosting feature for the calling GUI process. Window ghosting is a Windows Manager feature that lets the user minimize, move, or close the main window of an application that is not responding."

Not only that, but it seems to free up the CPU quite a bit, making OI processing faster - even on XP!

Cheers, M@

[img]http://www.vernonsystems.com/images/logo_main_ani.gif[/img]

How would one disable the windows 7 ghosting function on OI start up.

TIA

chris

How would one disable the windows 7 ghosting function on OI start up.

First declare the DisableProcessWindowsGhosting call in a DLL prototype record (See Chapter 7 in the Programmer's Reference Manual)

USER32

UINT	STDCALL DisableProcessWindowsGhosting( VOID )

Then

Call DisableProcessWindowsGhosting()

in your application. It seems sensible to do this as soon as possible so I put this in our application Startup Procedure (See ENV_STARTUP_PROC$ in the ENVIRON_CONSTANTS insert record), but presumably it would work just as well from the application main window's CREATE event.

I haven't come across any unwanted side effects so far, but I'd be interested in anyone's comments on doing this.

HTH, M@

[img]http://www.vernonsystems.com/images/logo_main_ani.gif[/img]

View this thread on the Works forum...