I can help you with #1. Unfortunately I don't know much about threading
yet, so someone else will have to help you with #2.
A "callback" (which in C# is implemented using a delegate) is a pointer
or some other handle to a method that you pass to another object so
that the target object can "call you back" for some reason.
For example, take a look at the Image.GetThumbnailImage method. I call
this method to scale some images that I'm displaying in a picture
gallery. However, scaling an image is a CPU-intensive operation that
can take a while. For a large, complicated image, it can go away for a
few seconds (on my machine) before it comes back with the scaled image.
So what if my user gets tired of waiting and just wants to abandon the
effort? Well, I would want to throw up one of those progress bar
dialogs with a "Cancel" button on it, so that my user can say, "Enough
already. Forget it!" and I would stop producing the thumbnail.
However, I'm stuck. I can't do that because I called the
GetThumbnailImage method, so my object no longer has control of the
CPU... it's sitting on the stack somewhere waiting for
GetThumbnailImage to return so that it can continue executing my code.
No matter what I do, I can't make my code execute because my thread of
execution is busy in some code deep inside the Image class.
So, GetThumbnailImage gives me the option to supply a "pointer" to a
function _in my code_ that it promises to call from time to time. If
_my_ callback function, which I wrote and passed to GetThumbnailImage,
ever returns false, GetThumbnailImage will stop scaling the image and
return to its caller... my method. So, now I have the power to ask
GetThumbnailImage to stop working. I can write a little method that
every time it's called checks to see if the user has pressed the Cancel
button and, if the user has pressed the button, returns false.
Without that callback method, once I called GetThumbnailImage I would
be stuck waiting for it until it returned with the scaled image, no
matter what.