http://msdn2.microsoft.com/en-us/library/ms700677.aspx
Applications that must block shutdown should use the new shutdown reason API
In Windows XP, Microsoft recommended that if an application needed to block shutdown, it should display its own UI explaining why it needed to do so, so users would be less frustrated when shutdown failed. As discussed earlier, Windows Vista will reduce user frustration when shutdown fails even more, by displaying new UI that lists all the reasons applications have provided for blocking shutdown.
In Windows Vista, if your application must block shutdown, in addition to returning FALSE or not responding to WM_QUERYENDSESSION, it should leverage this new UI by using a simple API to provide Windows with a reason string explaining why it is blocking shutdown. This API is straightforward:
•BOOL ShutdownBlockReasonCreate(HWND hWnd, LPCWSTR pwszReason);
•BOOL ShutdownBlockReasonDestroy(HWND hWnd);
•BOOL ShutdownBlockReasonQuery(HWND hWnd, LPWSTR pwszBuff, DWORD *pcchBuff);
Use of this API is detailed more fully later in this topic, as well as in the MSDN documentation for the individual ShutdownBlockReason() functions.
Again, note that this API does not replace the need to return FALSE (or delay responding) to WM_QUERYENDSESSION to block shutdown. Applications need to do this in addition to using the API. Applications that return TRUE to WM_QUERYENDSESSION will be closed at shutdown, regardless of whether they have used the API.
Also note that if your application has no visible top-level windows, it must use this API if it needs to successfully block shutdown. Such applications will automatically be terminated if they block shutdown without using the API.
Applications should no longer rely on always being able to block shutdown
If the user initiates a critical shutdown by clicking the “Shut down now” button from the new Windows UI discussed earlier, applications will not be allowed to block shutdown. In a critical shutdown, applications that return FALSE to WM_QUERYENDSESSION will be sent WM_ENDSESSION and closed, while those that time out in response to WM_QUERYENDSESSION will be terminated. The different procedure that is followed in a critical shutdown is summarized in Table 2 above.
In most cases, shutdown will not be critical, but applications should be prepared for the possibility of a critical shutdown. By following these recommendations, you can ensure that your application will handle critical shutdowns gracefully, without being terminated:
Make sure your application is prepared to respond to WM_ENDSESSION even if it responded FALSE to WM_QUERYENDSESSION.
Make sure your application responds to WM_QUERYENDSESSION as quickly as possible. If you need to do any time-consuming processing at shutdown, you should do it in response to WM_ENDSESSION. As indicated in Table 2, applications that respond TRUE to WM_QUERYENDSESSION will by default be given 30 seconds to do shutdown processing and respond to WM_ENDSESSION.
If your application needs to determine whether a shutdown is critical, it can check the ENDSESSION_FORCEFULSHUTDOWN bit in the lParam parameter of WM_QUERYENDSESSION.
Using the New Shutdown Reason API
The new shutdown reason API consists of three functions:
BOOL ShutdownBlockReasonCreate(HWND hWnd, LPCWSTR pwszReason);
BOOL ShutdownBlockReasonDestroy(HWND hWnd);
BOOL ShutdownBlockReasonQuery(HWND hWnd, LPWSTR pwszBuff, DWORD *pcchBuff);
Again, the best practice for Windows Vista applications at shutdown is that they should never block shutdown. However, if your application must block shutdown, Microsoft recommends that you use this API. The functions are simple to use.
When your application needs to block shutdown, it should call ShutdownBlockReasonCreate() to register a reason string, and pass in a handle to the window it uses to handle WM_QUERYENDSESSION.
When your application no longer needs to block shutdown, it should call ShutdownBlockReasonDestroy() to unregister its reason string.
If your application needs to determine what reason string it registered earlier, it should call ShutdownBlockReasonQuery() to retrieve it.
Windows will store the reason string associated with your application for the duration of the user’s session. The reason string store is not persisted when the user successfully shuts down; new sessions initialize an empty reason string store.
There are three main usage models for these functions.
The application knows ahead of time when it will need to block shutdown (preferred usage model)
The application only knows whether it will need to block shutdown during the shutdown process
The application has no visible top-level windows and needs more than 30 seconds to handle WM_ENDSESSION and perform shutdown processing
These are described in detail below.
Applications that must block shutdown should use the new shutdown reason API
In Windows XP, Microsoft recommended that if an application needed to block shutdown, it should display its own UI explaining why it needed to do so, so users would be less frustrated when shutdown failed. As discussed earlier, Windows Vista will reduce user frustration when shutdown fails even more, by displaying new UI that lists all the reasons applications have provided for blocking shutdown.
In Windows Vista, if your application must block shutdown, in addition to returning FALSE or not responding to WM_QUERYENDSESSION, it should leverage this new UI by using a simple API to provide Windows with a reason string explaining why it is blocking shutdown. This API is straightforward:
•BOOL ShutdownBlockReasonCreate(HWND hWnd, LPCWSTR pwszReason);
•BOOL ShutdownBlockReasonDestroy(HWND hWnd);
•BOOL ShutdownBlockReasonQuery(HWND hWnd, LPWSTR pwszBuff, DWORD *pcchBuff);
Use of this API is detailed more fully later in this topic, as well as in the MSDN documentation for the individual ShutdownBlockReason() functions.
Again, note that this API does not replace the need to return FALSE (or delay responding) to WM_QUERYENDSESSION to block shutdown. Applications need to do this in addition to using the API. Applications that return TRUE to WM_QUERYENDSESSION will be closed at shutdown, regardless of whether they have used the API.
Also note that if your application has no visible top-level windows, it must use this API if it needs to successfully block shutdown. Such applications will automatically be terminated if they block shutdown without using the API.
Applications should no longer rely on always being able to block shutdown
If the user initiates a critical shutdown by clicking the “Shut down now” button from the new Windows UI discussed earlier, applications will not be allowed to block shutdown. In a critical shutdown, applications that return FALSE to WM_QUERYENDSESSION will be sent WM_ENDSESSION and closed, while those that time out in response to WM_QUERYENDSESSION will be terminated. The different procedure that is followed in a critical shutdown is summarized in Table 2 above.
In most cases, shutdown will not be critical, but applications should be prepared for the possibility of a critical shutdown. By following these recommendations, you can ensure that your application will handle critical shutdowns gracefully, without being terminated:
Make sure your application is prepared to respond to WM_ENDSESSION even if it responded FALSE to WM_QUERYENDSESSION.
Make sure your application responds to WM_QUERYENDSESSION as quickly as possible. If you need to do any time-consuming processing at shutdown, you should do it in response to WM_ENDSESSION. As indicated in Table 2, applications that respond TRUE to WM_QUERYENDSESSION will by default be given 30 seconds to do shutdown processing and respond to WM_ENDSESSION.
If your application needs to determine whether a shutdown is critical, it can check the ENDSESSION_FORCEFULSHUTDOWN bit in the lParam parameter of WM_QUERYENDSESSION.
Using the New Shutdown Reason API
The new shutdown reason API consists of three functions:
BOOL ShutdownBlockReasonCreate(HWND hWnd, LPCWSTR pwszReason);
BOOL ShutdownBlockReasonDestroy(HWND hWnd);
BOOL ShutdownBlockReasonQuery(HWND hWnd, LPWSTR pwszBuff, DWORD *pcchBuff);
Again, the best practice for Windows Vista applications at shutdown is that they should never block shutdown. However, if your application must block shutdown, Microsoft recommends that you use this API. The functions are simple to use.
When your application needs to block shutdown, it should call ShutdownBlockReasonCreate() to register a reason string, and pass in a handle to the window it uses to handle WM_QUERYENDSESSION.
When your application no longer needs to block shutdown, it should call ShutdownBlockReasonDestroy() to unregister its reason string.
If your application needs to determine what reason string it registered earlier, it should call ShutdownBlockReasonQuery() to retrieve it.
Windows will store the reason string associated with your application for the duration of the user’s session. The reason string store is not persisted when the user successfully shuts down; new sessions initialize an empty reason string store.
There are three main usage models for these functions.
The application knows ahead of time when it will need to block shutdown (preferred usage model)
The application only knows whether it will need to block shutdown during the shutdown process
The application has no visible top-level windows and needs more than 30 seconds to handle WM_ENDSESSION and perform shutdown processing
These are described in detail below.
'Windows > MFC' 카테고리의 다른 글
GetProcessMemoryInfo (현재 프로그램에 메모리 점유율 알기) (0) | 2013.10.02 |
---|---|
reading mp3 id3 tag (mp3 테그 읽기) (0) | 2013.10.02 |
CString 에서 메모리관련 오류 발생시 m_szParsing.GetBuffer(6500); (0) | 2013.10.02 |
LIP 구분을 PC 에서 하기 (0) | 2013.10.02 |
CScrollView를 분할윈도우로 붙였더니 휠로 스크롤 되지않습니다 (0) | 2013.10.02 |