Highlighted
Absent Member.
Absent Member.
376 views

[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?
0 Likes
5 Replies
Highlighted
Absent Member.
Absent Member.

RE: [archive] XP display anomaly

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
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] XP display anomaly

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
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] XP display anomaly

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
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] XP display anomaly

I have also seen this behavior on Windows XP PC's. This also happens in a Thin Client environment with users that connect to Windows Server 2003.
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] XP display anomaly

If anyone reading this goes to the Developers Conference and attends the session being presented by Gisle Forseth on Developing ACUCOBOL-GT programs for Windows, (June 26 and 27), perhaps they can demonstrate this problem and he can get Acucorps attention to come up with an effective solution to prevent this anomaly from occuring whether during file processing, or a system call to an activeX or even just a command window. And if he has a solution, may come back and post it here?

Because this is something that did not occur with Windows 2000 or it's predessors, I really thiink that this is an issue between the wrun32 runtime and Windows XP...

Thanks,
Alan
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.