- You are here:
- Home
- CodeXchange
- All
- PowerBuilder
- Not Responding – Unresponsive Window Detection & Prevention
Not Responding – Unresponsive Window Detection & Prevention
- John Fauss
- Code Author
- Online
Less
More
- Posts: 8
3 years 8 months ago #340
by John Fauss
This message has an attachment file.
John Fauss created the code: Not Responding – Unresponsive Window Detection & Prevention
Not Responding is a single-window application developed in PB 2017 which shows how to test for and prevent a window that is executing a long-running process (a process lasting five seconds or longer) from being “ghosted” by Windows for being unresponsive.
Any window that does not process queued event messages from the thread’s message queue within five seconds is considered by Windows to be “unresponsive”. This is typically due to either (1) the window executing a long-running process, or (2) the window waiting for a response from an external source, such as the completion of a database query. The Windows Desktop Manager (WDM) task automatically hides an unresponsive window, replacing it with a “ghost” window that mimics the appearance of the unresponsive window, while appending “(Not Responding)” to the window’s caption/title. The user is able to interact with the ghost window in a limited manner and can close it, which terminates the unresponsive application.
When long wait times are the cause of unresponsiveness, the best approach to prevention is multi-threading. While multi-threading is possible in PowerBuilder, it is an advanced topic not demonstrated here. There are coding techniques that can detect and/or prevent unresponsiveness caused by long-running processes, however.
This application can execute a configurable, long-running process. The app illustrates:
A more detailed explanation of unresponsive windows and the coding techniques used in this example application will be available in a PB Tutorial titled “’Haunted’ Apps – How to Avoid Ghost Windows”.
Any window that does not process queued event messages from the thread’s message queue within five seconds is considered by Windows to be “unresponsive”. This is typically due to either (1) the window executing a long-running process, or (2) the window waiting for a response from an external source, such as the completion of a database query. The Windows Desktop Manager (WDM) task automatically hides an unresponsive window, replacing it with a “ghost” window that mimics the appearance of the unresponsive window, while appending “(Not Responding)” to the window’s caption/title. The user is able to interact with the ghost window in a limited manner and can close it, which terminates the unresponsive application.
When long wait times are the cause of unresponsiveness, the best approach to prevention is multi-threading. While multi-threading is possible in PowerBuilder, it is an advanced topic not demonstrated here. There are coding techniques that can detect and/or prevent unresponsiveness caused by long-running processes, however.
This application can execute a configurable, long-running process. The app illustrates:
- How to detect and recover from unresponsiveness caused by a long-running process.
- How to prevent unresponsiveness caused by a long-running process.
A more detailed explanation of unresponsive windows and the coding techniques used in this example application will be available in a PB Tutorial titled “’Haunted’ Apps – How to Avoid Ghost Windows”.
This message has an attachment file.
Please log in or register to see it.
Please Log in or Create an account to join the conversation.
Moderators: Appeon Administrator