[archive] XP display anomaly

[Migrated content. Thread originally posted on 21 March 2006]

We use the 5.2.1 run time with Windows.

I have attached a screen shot of the white screen display around the application window area.

With the advent of switching to Windows XP Pro workstations, we have started experiencing a screen display phenomenon during execution of our application. When the application is either very busy with file access, or computation, or when it calls an external routine (C$System directorycopy.bat, for instance) which executes for a while, the screen window expands to the entire screen, blanking out white around the application. If you double click the menu bar, it may return to the correct window size, but the application window is frozen and will not repaint. If you manage to move the window, you lose and cannot recover what was displayed until the application resumes processing and repaints.

In the attached window snapshot, the program is waiting for a locked record from another user -- the CPU is not busy, so windows has plenty of time to repaint the window.

What bothers me the most is that if the application does resume momentarily and does some additional I/O to the screen, and then stops again, the screen DOES NOT repaint. The user may not see an important message.

This behavior was never observed to happen on Windows 98, Windows NT workstation or Windows 2000, only XP.

Has anyone else seen this? Does anyone know how to prevent this?

We also noticed this when many users started using XP. I've since learned that this phenomenon is called a "ghost window". I know of one particular ECN done where the ghost window would appear during heavy I/O processing. It would've been well after 5.2.1.

I'm not sure what version of the runtime this would work in, but there is an environment variable called "FILE-IO-PEEKS-MESSAGES" that can be turned on. I'd suggest you check with Technical Support to get the full answer on this issue.

From what I understand, the ghost window will appear whenever Acucobol isn't notifying Windows that it's active. This occurs every few seconds normally, but there are some actions that can be done with the runtime that will delay that notification and cause the ghost window. Windows thinks that the application is non-responsive and puts up the ghost window. Anyway, technical support would be your best bet to resolving this problem even though I'm sure you'll get many more responses in this forum.

Rob

[Migrated content. Thread originally posted on 21 March 2006]

We use the 5.2.1 run time with Windows.

I have attached a screen shot of the white screen display around the application window area.

With the advent of switching to Windows XP Pro workstations, we have started experiencing a screen display phenomenon during execution of our application. When the application is either very busy with file access, or computation, or when it calls an external routine (C$System directorycopy.bat, for instance) which executes for a while, the screen window expands to the entire screen, blanking out white around the application. If you double click the menu bar, it may return to the correct window size, but the application window is frozen and will not repaint. If you manage to move the window, you lose and cannot recover what was displayed until the application resumes processing and repaints.

In the attached window snapshot, the program is waiting for a locked record from another user -- the CPU is not busy, so windows has plenty of time to repaint the window.

What bothers me the most is that if the application does resume momentarily and does some additional I/O to the screen, and then stops again, the screen DOES NOT repaint. The user may not see an important message.

This behavior was never observed to happen on Windows 98, Windows NT workstation or Windows 2000, only XP.

Has anyone else seen this? Does anyone know how to prevent this?

Thanks Rob...

The configuration variable is actually FILE_IO_PROCESSES_MESSAGES and while it helps somewhat, it is not a fix.

In particular, it does not seem to help when the program has performed a system call and is waiting for it to return.

Any other ideas and insights are welcome.

Alan

[Migrated content. Thread originally posted on 21 March 2006]

We use the 5.2.1 run time with Windows.

I have attached a screen shot of the white screen display around the application window area.

With the advent of switching to Windows XP Pro workstations, we have started experiencing a screen display phenomenon during execution of our application. When the application is either very busy with file access, or computation, or when it calls an external routine (C$System directorycopy.bat, for instance) which executes for a while, the screen window expands to the entire screen, blanking out white around the application. If you double click the menu bar, it may return to the correct window size, but the application window is frozen and will not repaint. If you manage to move the window, you lose and cannot recover what was displayed until the application resumes processing and repaints.

In the attached window snapshot, the program is waiting for a locked record from another user -- the CPU is not busy, so windows has plenty of time to repaint the window.

What bothers me the most is that if the application does resume momentarily and does some additional I/O to the screen, and then stops again, the screen DOES NOT repaint. The user may not see an important message.

This behavior was never observed to happen on Windows 98, Windows NT workstation or Windows 2000, only XP.

Has anyone else seen this? Does anyone know how to prevent this?

Alan,

This is something we've noticed recently as well and I'd love to hear others comments on it. I'm not sure what to do to prevent those ghost windows in that circumstance. We also see it when performing ActiveX calls that take a while before coming back to the COBOL app.

Rob