On 08/08/13 11:52, Michael Schnell wrote: > On 08/08/2013 12:34 PM, Lukasz Sokol wrote: >> Hello, >> >> I am making a Pascal wrapper for a library, which states in its API >> description: >> >> " Note that the Callback function will be called from an >> independent child thread, not from the Applications Window thread. >> It should not therefore be used to draw data directly to a Windows >> screen. The safest use of the callback is to use a threadsafe >> interface (such as Windows messaging) to pass the message to >> Windows for handling by the Windows thread. " >> > AFAIU: The callback is just a callback. So you can handle it in the > normal way (either in an application, in a command line tool without > a main form or in a dll.) You just can't do any GUI stuff in that > callback. > > I understand that you in fact don't want to do that, anyway. > > -Michael >
Oh, I missed the whole point ... sorry. in fact I DO want to be able to call gui-interfacing functions of the form. The library I am loading (dynamically) will be giving me callbacks when something changes in an external USB device... When that happens, I want to be able to do e.g. MyObject.OnStateChange := TForm1.ShowStateChange; and e.g. safely call ShowMessage or display a custom dialog box, (as well as I will be calling procedures/functions of another non-vis object(s) doing something else with the data provided by callback) So it seems, if I call my objects' InternalCallback function from the installed callback, then it's my object that has to care for thread safety to the GUI then ? (Henry Vermaak mentions QueueAsyncCall, going there... Kind Regards, Lukasz _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal