I am using EnumDisplayMonitor to retrieve information about the displays connected to a system. Calling EnumDisplayMonitor requires that a callback function is provided which is then invoked to receive details of each enumerated monitor. My question is when does EnumDisplayMonitor return? Is it immediately or does it block until the callback has been called for each enumerated monitor? I want to process a data structure that will have been altered by the callbacks and I need to know if it's safe to do it immediately after the EnumD开发者_如何学CisplayMonitor call. If the call doesn't block is there a way to check that the callback has finished being called? This might be a general question about callbacks....
e.g.
BOOL CALLBACK MonitorEnumProc(
__in HMONITOR hMonitor,
__in HDC hdcMonitor,
__in LPRECT lprcMonitor,
__in LPARAM dwData)
{
// Alter something here - e.g. Add lprcMonitor to a list.
}
int main()
{
EnumDisplayMonitor(NULL, NULL, MonitorEnumProc, 0);
// Can I rely on EnumDisplayMonitor to have finished making calls to
// MonitorEnumProc at this point?
}
I've checked the MSDN entry and it does not help in this respect and I would confirm by experiment but I don't have enough monitors to test it reliably.
It returns when it has finished calling your callback functions. So the sequence of events looks like this:
Enter: EnumDisplayMonitor
Callback: MonitorEnumProc
Callback: MonitorEnumProc
Callback: MonitorEnumProc
...
Leave: EnumDisplayMonitor
All the Windows API routines of this ilk behave this way, e.g. EnumProcess
, EnumWindows
etc.
Code has to run in the context of a thread and if such an enumeration routine were to return immediately and call the callbacks asynchronously, it would have to spawn a thread to do so. You can apply the principle of least surprise here!
精彩评论