TurboFloat: Callback procedure - how to avoid it?

Hi Wyatt,

In TF, the callback procedure is being called and executed. But my software crashes right after the procedure end. I don't know why. I will contact the support team of the company to look into that, but this will take time.

I see there is a function called HasLease() but I see no way how to use TF without having to setup the callback function. How can I do that?

If this is not possible, this would be great to have a function that does the contrary of callback: our software will call TF from time to time to get the status: TF_OK, TF_CB_*. So the DLL could receive the TFS events has usual, but instead of calling the callback function, it would simply store the status in memory so that on the next call of HasLease() (with potential return value TF_OK, etc. + all TF_CB_) the good status would be returned.

Then this would be possible to avoid the callback problem by having a simple timer that calls TF dll to get the last status it got from TFS. (So if TFS refresh is every 30 minutes, even if I call TF every seconds, the status would effectively not be updated before 30 minutes - it's not making a status-refresh call, simply reading the last status.)

So could be possible to call RequestLease() without having to call to SetLeaseCallback(). (Or maybe call it with a Null pointer to explicitly tell the DLL : "don't call us, we'll call you". So the DLL would know it is setup properly and ready to call RequestLease() in no-callback mode.)

Thank you for your help,Alexandre Leclerc

In TF, the callback procedure is being called and executed. But my software crashes right after the procedure end. I don't know why. I will contact the support team of the company to look into that, but this will take time.

The callback function is being called from a separate thread. So, you need to "sync" threads before the callback function can do anything on your main app's thread.

Also, it appears that PCSoft doesn't support callback functions of the CDECL calling convention. We'll release a STDCALL version of TurboFloat.dll in the next release.

Hey Wyatt,

I just want to thank you for all the pain you took to go and search for the problem with the programming language I'm using! I'm very much surprised (because it is not a well known language in North America, and much less in non French speaking countries).

So kudos for that! I sent PCSoft a full test program for this crash this afternoon so they tell me what is going on but you were just faster! (Of course, you also know how your technology is working - on my side I have two black-boxes and I can't investigate much.)

That being said, keep me informed (even by email) when the next release is available because this project will go live very soon.

Again, thank you very much for your excellent help! It's a pleasure to do business with you.Alexandre Leclerc

I just want to thank you for all the pain you took to go and search for the problem with the programming language I'm using!

It's no problem, I'm glad to help.

That being said, keep me informed (even by email) when the next release is available because this project will go live very soon.

I've sent you the stdcall version of the current version of TurboFloat. The next version of the TurboFloat library package we release will have the stdcall version included alongside the normal cdecl version.

You should note that all the functions use the stdcall calling convention -- so you'll have to change the API definitions for the TurboFloat functions so they use the STDCALL not the CDECL calling convention.

Hi Wyatt,

The new DLL works perfectly: there are no crash after callback function call.

Thank you very much for your very quick release!

As for STDCALL and CDECL, WinDev is doing it transparently - we can't specify it. As I understand it now, the problem is not in making a STDCALL or CDECL call to a DLL (which is done correctly in both case) but with callback functions only. Only STDCALL is supported by WinDev for callback.

In fact, would it be possible for you to produce a single DLL but with a callback function for CDECL convention and one for STDCALL convention, and simply specify which calling convention to use when calling SetLeaseCallback()? (I ask the question out of ignorance - if two function pointers can be pre-defined for their respective calling convention.)

Best regards,Alexandre Leclerc

In fact, would it be possible for you to produce a single DLL but with a callback function for CDECL convention and one for STDCALL convention, and simply specify which calling convention to use when calling SetLeaseCallback()?

Yes, it would be possible. But we're just using separate "stdcall only" DLL because it's easier for us (it's a simple flag switch when compiling). Also, some other languages (like VB / VBA) only support stdcall, so we'd need a separate DLL for customers that use those languages anyway.

Reply
Discard post