Hey, All
I am trying to discribe "What is a CALLBACK Function", and the
best I can come up with is:

Windows is Event driven, in other words; The Main Windows Program
(WinMain) posts or sends a message requesting that an
action take place, If at that time the Action could not be completed
for any of many possible reasons then the WinMain Function will continue
to "CALLBACK" the "Message Handling" Function/Procedure until the
Action is either processed or a message is sent to stop trying.

Is this anywhere near accurate or complete ???

Comments ???

Thanks,
Brad
Posted on 2002-02-21 02:51:25 by Brad
Forum BenchMarks :grin:

Hey, All

I realize that this question is NOT really an Assembley related
question---however it IS a Win32 related question.

I posted this "Windows Programming Theory" Question
at two excellent Forums, and so far the "BenchMarks" are:

BenchMarks: For Answers/Comments

Win32ASM 0
PowerBASIC 2



:grin:
B
Posted on 2002-02-21 07:03:16 by Brad
Brad, your question is not specific to Win32asm, whats more a quick google search will give you plenty of answers.
If you can't be bothered with google for what ever reason, I'm sure MSDN will also tell you exactly what a callback function is, and of course in MS windows, who is better to describe the "idea" better than Bill Gates and his cronies themselves?

What is more, the idea that you are trying to prompt for a response by comparing this message board to others is quite transparent as a method of gaining information (and often refered to as trolling I believe) is somewhat insulting.

If you really want to describe some Windows functionality (for what I can only presume is a piece of homework, why else would you need an accurate description of a well documented feature in your own words?) I can only suggest that you read a book on the subject.

Mirno
Posted on 2002-02-21 08:00:54 by Mirno
Mirno,

Look!!! You Guy's are "Brillant Genius's"

I know any answer I would get here---would be a LOT better
than from google or MSDN :)

Wasn't trying to compare----I'm already sold!!!

These are Both two "Excellant Forum's the Best on the Internet!!"

Just trying to "spark" some discussion :grin:

Brad
Posted on 2002-02-21 08:11:04 by Brad
oCallback function is a type of functions that is called by
Windows, not your code.
Though it is possible for your code to call it directly or indirectly
that a prog can call it's own callback function, the main reason
for existing callback function is to give your OS address of the
fuction that should be called by OS in specified cases.
So the main features of callback function is that:
- it is called not by your code but by other code with control
some events that your code doesn't (in such way your prog
is given a chance to "take a part" on controlling the events
it can not (or not supposed to) control directly
- it returns not to your code but to a different code - code of
the caller (it , for example, can clearly explain why some regs
such as ebx,edi,esi should be preserved and restored and why
it is important only in callback functions, and in other code (not
callback) it is upto you,optionall wether to preserve them or not:
since Windows callback function returns to OS code, and OS code
uses ebx,edi,esi then changing them misdirect OS code when
it uses values of ebx,edi,esi assuming that they have not been
changed by the callback function)

I'll say again the main reason for existing callback function type:

To give your app a chance to take part on controlling subsequenses of OS events that your app can not control directly.
Posted on 2002-02-21 08:15:31 by The Svin
WOW!!! , Thanks, Svin

That Clearify's a Lot!!!

Brad:grin:
Posted on 2002-02-21 08:21:18 by Brad
Svin,
Can I have your permission to copy this to the other Forum?---
giving you credit----of course!!!

They would really like it---
Thanks, Brad
Posted on 2002-02-21 08:24:05 by Brad
Brad,

This following text is written for PowerBASIC, you can have the help file after I do a bit more work on it.

=================
The main message handler is often referred to as a "callback" and it has to do with the way Windows manages the messages for the main window. The message handler is NEVER called by the application program, its address is placed in the WNDCLASSEX structure and Windows calls the message handler back when messages need to be processed by the window. In the following schematic, if a user selects an item from the menu or clicks on a button, the message from that control or menu is sent by the operating system to the main window's message handler.
=================

Regards,

hutch@movsd.com
Posted on 2002-02-21 08:31:17 by hutch--
A callback is a pointer to some function (who under most languages will be type checked), which can then be called within some standard body of code (such as the Win32 API).

This allows a certain level of user control within the API, and enhances functionality. It also takes the strain off the API as to how to deal with error and unexpected cases, where a separate function can be passed to the API detailing how to deal with these unusual cases.

Mirno
Posted on 2002-02-21 08:34:12 by Mirno
Brad:
Of course, you can copy anything I post to the board to where
you'd like to copy it.
I ask just for one thing - please, correct my spelling and English commands.
Steve:
CallBack function may be not necessarilly Window callback function.
Many API functions asking for callback functions, ComDlg, many
enum functions etc.
And I believe, you know it. I have a blurred feeling that I saw
in some of your procs in M32lib that you use callback functions
needed for some of API calls.
Directory dlg may be?...
Posted on 2002-02-21 09:02:01 by The Svin
Thanks,
Svin :grin:
and,
Hutch, can't wait for the HelpFile, the start Looks Great :grin:

Brad
Posted on 2002-02-21 09:25:25 by Brad
Alex,

You are right but I have a partly finished help file for PowereBASIC which is where Brad is posting it and the text I posted was for the WinMain and WndProc. With general purpose callback functions, there is no real restriction on what you do with them.

I have written them from both ends when a function in a DLL calls back a function from its parent EXE file, usually in a seperate thread as well.

It usually means you pass the address of the callback you have written to the function in the DLL which literally calls it back from the DLL.

It can also be done from a seperate thread in the same app for things like halting processing of another process within the calling app.

Regards,

hutch@movsd.com
Posted on 2002-02-21 09:30:46 by hutch--
what follows might be wrong, so like Brad I'm politely asking for corrections if any :)

A "callback" is not limited to OS APIs (much less Win32). The term can be applied to any 2 'codes' (I really need a better term for that) that 'communicate' (and that :D) with each other. Take for example an application with an embedded script engine. A script for that app can define a callback function which the app can call according to a certain events within the main app (perhaps errors). The script may not, or is not supposed to call that function itself.

hope that was clear :grin:

.pix
Posted on 2002-02-21 12:43:44 by pixelwise
'codes' (I really need a better term for that)


Threads - separate execution streams that share most of the program resources, like memory addresses & stack or whatever

or Proceses: where they don't share much

Just putting words to your meaning


IMHO I like svin's definition better because it's less clinical & explains things rather than defines them
Posted on 2002-02-21 13:03:51 by Mutant Slime
:alright:
I'll take note of that :)
Posted on 2002-02-21 13:11:53 by pixelwise


CallBack function may be not necessarilly Window callback function.
Many API functions asking for callback functions, ComDlg, many
enum functions etc.
And I believe, you know it. I have a blurred feeling that I saw
in some of your procs in M32lib that you use callback functions
needed for some of API calls.


Hi svin,
well i've a little doubt about callback
the os provides some api to enter callback addr of the function
we want the os calls when something happens
but our code is always code by the os from the context we've created or as for SetWindowsHook() we've to decide which context we wanna be inside when the function is called
That means that when we install a callback with some api
es:
SetWindowsHook()
its requested the handle of the instance the function stays in and thats right to indentify the context ur code lives and even the thread ID the hook code has to be associated
That means when ur hook code is called by the os it performs a context and a thread switch right ?
It shouldnt be a simple:
push param
call addr_callback_function

the os should provide some mechanism to call our code from the right context (so its context switch coz the os donest live in our context) and in the right thread
How is it implemented ?

Tnx a lot
NikDH
Posted on 2002-02-21 18:43:41 by NikDH
It's a good question, but too complex to explain in short way.
In short:
- By managing kernel objects
- A little bit differs on different OS.
I haven't seen yet full and complite reference on the issue.
But at least a lot can be explained through works (books)
by Matt Pietrek (for 9x), J.Richter (for all), and M.Russinovich + D.Solomon (NT4,NT5).
All this tracking is done through internal system tables controlling
kernel objects. Even handles we get not real handles but handles
for us (exept may be only hWnd handles - the same for every process).
Posted on 2002-02-21 19:13:46 by The Svin
Brad,

By the time you exhaust the range of answers in here, you will be able to write callback functions in hex. :)

Lets try this as an example. It is easy enough to write both an application and a DLL that work together where you pass the address of a function to the DLL and it in turn CALL BACK the function address that you passed to it.

You write code like this if you need a result posted back to an EXE file from the DLL you have written among many other things. It is often done from a seperate thread that calls the DLL so that the operation is asynchronous. There is an app in the MASM32 example code that Jibz wrote that does exactly this without the DLL.

The library that handles the data compression periodically sends a progress result BACK to another function which has a function written to display the progress in compression.

With an operating system callback, the only difference is that you do not normally have access at the code that does the calling back but it effectively works the same way.

A WNDCLASSEX structure passes the address of the Wndproc to the operating system which in turn transfers any messages that are sent to the window directly to the WndProc function. You have not written the code that does the calling back but you do write the code that is called by the operating system.

There are enough variations in the operating system with different types of callback routines, enumeration of windows is just one of them but they work more or less the same way. Code within the operating system that calls a function that you must write that must be in a specific format to work properly.

Regards,

hutch@movsd.com
Posted on 2002-02-21 19:55:35 by hutch--
Exactly, Hutch

That is Precisely why I posted my question to this "World Class Forum", :grin: , instead of listening to tech writers, at google & MSDN, try to explain what they don't know----

Thanks,B
Posted on 2002-02-21 21:11:13 by Brad