I used SetWindowsHookEx to install a hook procedure for monitoring the message processing. The hook types are WH_CALLWNDPROC and WH_CALLWNDPROCRET. But I found that sometimes the calling of hook procedures for WH_CALLWNDPROC and WH_CALLWNDPROCRET was not matched such as when calling the CreateWindowExW function. I want to know why. Is there someone who can help me? I would appreciate your answer.
Related
With our MFC app a normal clean exit calls CWinApp::ExitInstance() and then CWinApp::~CWinApp. But if exit(1) is called, only CWinApp::~CWinApp fires, ExitInstance is skipped. I know exit(1) shouldn't be used with MFC, but we have a legacy app that uses it in 100's of places and I'm wary of replacing it with a PostMessage or something totally different.
What is the best solution here?
Do some magic windows thing so ExitInstance is actually called
Replace exit(1) with something else even though we don't want to
Use atexit somehow to call ExitInstance
Have our CWinApp dtr call ExitInstance, if it hasn't been called already
Try to empty out ExitInstance and just do all cleanup in dtr. Probably not possible?
Other?
It depends on the sort of work you're doing in ExitInstance. You have to make sure you understand what it's doing, and how changing the context will affect it.
With that caveat, the most obvious approach is to move the work you're doing in ExitInstance to a separate procedure, MyExitInstance. Call MyExitInstance from ExitInstance. Replace the calls to exit with calls to a procedure that calls MyExitInstance and then calls exit.
Note that I'm assuming here that's in only your own code in ExitInstance that matters, not anything the framework may be doing for you.
I am looking for a way to schedule a callback function at a regular frequency (say 1hz) within the NT kernel. Is there any framework support for that? I read in one of the posts that a timer object can be used for that, but I did not find any example or any documentation for this use case. Any help would be appreciated.
You are looking for the SetTimer function in the Windows API. It allows you to pass a callback function pointer.
Note that you must have a working Windows message pump for this function to work - the callback occurs as part of the message processing. The OS doesn't just interrupt your program and jump to the callback function.
On Unix: I’ve been through FAM and Gamin, and both seem to provide a client/server file monitoring system. I would rather have a system where I tell the kernel to monitor some inodes and it pokes me back when events occur. Inotify looked promising at first on that side: inotify_init1 let me pass IN_NONBLOCK which in turn caused poll() to return directly. However I understood that I would have to call it regularly if I wanted to have news about the monitored files. Now I’m a bit short of ideas.
Is there something to monitor files asynchronously?
PS: I haven’t looked on Windows yet, but I would love to have some answers about it too.
As Celada says in the comments above, inotify and poll are the right way to do this.
Signals are not a mechanism for reasonable asynchronous programming -- and signal handlers are remarkably dangerous for the inexperienced and even for the experienced. One does not use them for such purposes voluntarily.
Instead, one should structure one's program around an event loop (see http://en.wikipedia.org/wiki/Event-driven_programming for an overall explanation) using poll, select, or some similar system call as the core of your program's event handling mechanism.
Alternatively, you can use threads, or threads plus an event loop.
However interesting are you answers, I am sorry but I can’t accept a mechanism based on blocking calls on poll or select, when the question states “asynchronously”, regardless of how deep it is hidden.
On the other hand, I found out that one could manage to run inotify asynchronously by passing to inotify_init1 the flag IN_NONBLOCK. Signals are not triggered as they would have with aio, and a read call that would block blocking would set errno to EWOULDBLOCK instead.
This may seem to be a duplicate question for Is KillTimer necessary?, but i would like to confirm this with credible source.
Does destroying window really free the resource allocated by the OS for the timer? (does DestroyWindowsTimers really get called let alone if such function actually exists? if so, where?)
No, it is not necessary. From the documentation of DestroyWindow (with emphasis added):
The function sends WM_DESTROY and WM_NCDESTROY messages to the window to deactivate it and remove the keyboard focus from it. The function also destroys the window's menu, flushes the thread message queue, destroys timers, removes clipboard ownership, and breaks the clipboard viewer chain (if the window is at the top of the viewer chain).
Doing a google search the only actual real looking reference to it looked to be some Win2k source code. The url ended with /Censorship/win2k_sources/private/.../timers.c, I'm assuming from the source code leak a while back. I did not look at the code, nor will I post a link here.
That function most likely exist - something like that almost has to exist for timers linked to window handles - since the timer message is delivered to a specific window handle.
I can't see anywhere in the documentation that states that you don't have to call KillTimer to get rid of a timer. So based on the documented contract, you need to call KillTimer. In practice Windows will probably clean it up for you, but since that is undocumented behavior you should write your code to follow the documented behavior and call KillTimer on all your timers.
I get the idea of parameters in functions, but I don't know what an event is. I have also heard of JavaScript function events but since I have no js experience, I don't know what they are.
There is nothing special in Lua that can be called 'event'. I guess you are talking about general events (from Wikipedia):
In computing an event is an action that is usually initiated outside the scope of a program and that is handled by a piece of code inside the program
An example of events are a mouse click, key press, download finished, anything you can imagine.
In order to react to an event, you need to write a so-called handler, sometimes also called listener or callback, which is a piece of code that you register to react to a certain event. The available events, handling process and handler registration are all dictated by the library/framework you are using, i.e. it's not Lua specific, but Lua does provide functions as way to write handlers.
For example, in Corona SDK (overview of events/listeners), you can handle the 'touch' event as follows:
Runtime:addEventListener("touch", function(event)
print("A touch event is being handled")
...
end)
There is no such thing as an 'event' in a standard Lua function. Perhaps there is some library that provides you with them, or you could script your way around to emulate the wanted behaviour.
You can get more concrete answers if you provide info about what you want to accomplish, and show some code.