Forum > Windows
[SOLVED] ShutdownBlockReasonCreate and handles...
nrs1022:
Hello everyone! I have an app on Windows without visible windows that runs different background jobs and the app has no user interaction at all (it's like a service).
The app has a thread processing Windows messages like WM_QUERYENDSESSION and WM_ENDSESSION. When user logouts, my app receives the WM_QUERYENDSESSION, but some background jobs on my app needs more than 5 seconds to be cancelled. Because Windows Vista and onwards implements "reasons" to delay shutdown, I wish to implement it on my app but I have a problem.
Declaration for ShutdownBlockReasonCreate is:
Function ShutdownBlockReasonCreate(Handle: hWnd; Msg: lpcwstr): Bool; StdCall; External 'user32';
My problem is with parameter "Handle". According with MSDN http://msdn.microsoft.com/en-us/library/windows/desktop/aa376877%28v=vs.85%29.aspx "This function can only be called from the thread that created the window specified by the hWnd parameter. Otherwise, the function fails and the last error code is ERROR_ACCESS_DENIED.".
Which is the "handle" to use? The handle of my main thread? I've read on Delphi examples using "Application.Handle" as parameter, but I don't find an equivalent on FPC. If I use the thread handle (The thread used for processing the messages) received return code 87 (ERROR_INVALID_PARAMETER), and Hwnd can't be 0 because I received code 5 (ERROR_ACCESS_DENIED).
Thank you to all for your help!!! And sorry for my bad english...
Nicolas.
taazz:
You have a thread that handles messages which is impossible with out a window handle, so call it from the thread and passing that window handle in the handle parameter.
engkin:
Use Win32WidgetSet.AppHandle from Win32Int:
--- Code: ---uses
.., Win32Int;
...
ShutdownBlockReasonCreate(Win32WidgetSet.AppHandle,...
--- End code ---
or use WidgetSet.AppHandle from InterfaceBase:
--- Code: ---uses
.., InterfaceBase;
...
ShutdownBlockReasonCreate(WidgetSet.AppHandle,...
--- End code ---
I guess...
Edit:
If AppHandle didn't work, here is one more guess. Try Application.MainFormHandle
2nd Edit:
Welcome to FPC/Lazarus.
nrs1022:
--- Quote from: taazz on July 31, 2014, 04:33:53 am ---You have a thread that handles messages which is impossible with out a window handle, so call it from the thread and passing that window handle in the handle parameter.
--- End quote ---
Hello taazz! That's great and works. Thanks! Thread receives the message WM_QUERYENDSESSION, and I can use the function: String is displayed as reason and Windows waits to my app. Unfortunately, the thread is locked waiting for jobs to finish without sending FALSE as response to WM_QUERYENDSESSION to Windows. Apparently Windows continues to wait (I can't test it enough to verify), but according to MSDN app could be forcely closed because FALSE has not been sent.
--- Quote from: engkin on July 31, 2014, 04:53:08 am ---Use Win32WidgetSet.AppHandle from Win32Int:
--- Code: ---uses
.., Win32Int;
...
ShutdownBlockReasonCreate(Win32WidgetSet.AppHandle,...
--- End code ---
or use WidgetSet.AppHandle from InterfaceBase:
--- Code: ---uses
.., InterfaceBase;
...
ShutdownBlockReasonCreate(WidgetSet.AppHandle,...
--- End code ---
I guess...
Edit:
If AppHandle didn't work, here is one more guess. Try Application.MainFormHandle
2nd Edit:
Welcome to FPC/Lazarus.
--- End quote ---
Hello engkin and thank you :) ! Unfortunately, Application.MainFormHandle and the units are not working because I'm on pure Windows API and I'm not using Lazarus (Only FPC). Until now, I'm out of luck trying to replace the "Application.handle" in my case.
taazz:
--- Quote from: nrs1022 on July 31, 2014, 05:27:15 am ---Hello taazz! That's great and works. Thanks! Thread receives the message WM_QUERYENDSESSION, and I can use the function: String is displayed as reason and Windows waits to my app. Unfortunately, the thread is locked waiting for jobs to finish without sending FALSE as response to WM_QUERYENDSESSION to Windows. Apparently Windows continues to wait (I can't test it enough to verify), but according to MSDN app could be forcely closed because FALSE has not been sent.
--- End quote ---
How about change the wait code to add some time out and respond to messages, then check if the threads have ended and restart wait with time out again.
Navigation
[0] Message Index
[#] Next page