How does the callback mechanism work ?
Where on the web can I find a complete explanation ?
callback method/mechanism
How does the callback mechanism work ?
Where on the web can I find a complete explanation ?
A Callback function?
That is a Windows programming question and would get more detailed response there.
Quickly, a callback is a special type of function used in Windows programming. It is a nested switch/case statement. When a message is generated in Windows by the user (or OS) it is passed to the callback of the relevent program. Along with the msg is information as to what type of action took place ect. ie ifthe user changes the size of your window a WM_SIZE msg including the new x,y cood is passed to your callback function where you deal with it.
A complete explanation?
I'm still looking but try Petzold's web site. He wrote the Programming Windows series which are consideed to be among the best refrences for begining programming with the WIN32 API.
Last edited by novacain; 11-08-2001 at 03:33 AM.
"Man alone suffers so excruciatingly in the world that he was compelled to invent laughter."
Friedrich Nietzsche
"I spent a lot of my money on booze, birds and fast cars......the rest I squandered."
George Best
"If you are going through hell....keep going."
Winston Churchill
Ok, I found the webpage ...
Complete explanation :
- registration of callbacks between two processes
- how is it handled
- and much more
Hehe when I first read the callback method in the title I was thinking back to the old BBS. Sorry can't help you with this one.
A callback function is a function that you provide that another function can call.A good example is qsort(). You tailor qsort to your needs by providing a function that the qsort function can call.That comparison function is a callback function.
Free the weed!! Class B to class C is not good enough!!
And the FAQ is here :- http://faq.cprogramming.com/cgi-bin/smartfaq.cgi
callsbacks are not relegated to windows programming only. callbacks are used in every O/S in the world. The basic principles are:
In your application you create a global function (it resides in the heap, not on the stack) with a specific set of parameters in and out. Next you tell the O/S (registration) the address of that function. Or, instead of the O/S, it could be another code-block you've written, such as an application that calls plug-ins.
In some cases, the only tricky part of this is keeping track of your stackframe. The global 'stackframe' contains all the registers setup for your application that points to where your global variables are, jump tables, program counter, etc.
The reason you keep track of this is because while your in your application, you can access your variables and call other functions-- to do this your stackframe must be the one currently loaded. If you don't do this, and the O/S (which uses it's own stackframe), calls your callback and you don't save their stackframe and insert your own while you're running, the program will trash memory and/or crash.
Here is a perfect example--
Let's say you are writing a video game, and you want it to run at the correct speed, no matter what processor you're running on. in order to do this, you would created an interrupt-driven clock (a watchdog timer, as it were).
You create a function that checks a tick counter, or other O/S mechanism for following the passage of time. When x-time has elapsed (say 1/2-second or so), your function set's a global variable in your application to TRUE.
clockFlag = TRUE;
The way this works is, you then register that "callback" with an interrupt process (such as a time manager) in the O/S. the callback has a specific prototype, and you request that the O/S call this function every xths of a second. I could 5 every 5/60ths of a second, or every 1/100th of a second, or perhaps finer resolution, depending on what you need.
When you exit your program, you remove this callback from the time manager, so that it won't still be trying to execute your callback after you've exited.
So, let's say the time manager calls your function every 5/60 of a second. Everytime your function is called, you check elapsed system time, until 30/60 of a second has passed. At which time you raise the flag 'clockFlag'.
The callback then restores the stackframe and returns to the O/S.
Your application blithely glides along, and all your frame-rate code checks clockFlag. If it's true, it's time to draw another frame. Once drawn, the application clears clockFlag = FALSE. If it hasn't become true, the program continues building the image, but doesn't yet display it.
see how coolly this concept can be used?
Thanks for your explanation 'in depth'.
Just wondering, the registered callbacks aren't freed
when the application stops ?
It depends where the callback is allocated. If it is allocated in the System Heap, then no, it resides as long as the O/S runs. If it is allocated from the Application heap, then when the application terminates, the callback code is no longer valid.
This is important--
Note the last "the callback code is no longer valid."
Even when your application terminates, whatever bytes were in RAM at whatever locations, are still there. The space is just marked "unused" by the O/S.
So, the problem occurs if you created a callback that is serviced by a system interrupt (like the clock example above). The callback code gets unloaded, but the interrupt will still try to jump to that code location. As such, if might start executing the values that are left in RAM, or if they've been destroyed, it will crash.
enjoy.
