--- In [email protected], "i2phd" <i2...@...> wrote:
>
>
> Delhi and C++Builder are inflated with compiler bloatware, so using the
> lean and mean Turbo C++ the size of the DLL went considerably down...
>
To be exact I updated my AboutBox to be the same in Delphi and C++ and now the
value is 62.5kB, still 7 times smaller.
Turbo Explorer is a stripped down version of C++ Builder (even the About Box
says Borland C++ Builder).
One of the differences between Turbo Explorer (free) and Turbo Professional
(commercial but no longer produced) is the fact that components cannot be
installed in the IDE. I was wondering if you used third party components in
Winrad as Turbo Explorer can compile C++ Builder projects. I downloaded the
source code and will try.
> Well, the handling of a negative value as return from the SetHWLO call was
> planned to be implemented in V1.33 - But then I decided (almost abruptly) to
> stop developing Winrad, which remained at 1.32...
> So Winrad does not inspect the return value from SetHWLO to behave
> accordingly... if you inspect the distributed source code, you will see for
> yourself...
>
I realized that I am using Winrad 1.4 and it seems that SetHWLO act properly
except on a new install where the LO is set to 0 and only after the first
SetHWLO call: if later on I try to change the LO with the mouse - let say 10Hz
- I return -50110000 and Winrad calls again to set the LO to 50110000. This is
why I wanted to use the CallBack function and it works perfectly in C++.
InitHW
SetCallback
ModeChanged
OpenHW
SetHWLO: 0
Too Low <- Here I do not use the callback, I just return -50110000
TuneChanged
InitHW
SetCallback
ModeChanged
OpenHW
SetHWLO: 0
Too Low <- Here I call CallBackPtr(-1, 101, 0, 0);
before returning the negative value
TuneChanged
GetHWLO
SetHWLO: 50110000
GetHWLO
IFLimitsChanged
TuneChanged
> About the callback, there is one thing that I can do, If you prepare for me a
> DLL that somewhat works even without any hardware connected, then I can
> execute Winrad in debug mode, and check what happens when the DLL calls the
> callback. You can just prepare a skeleton where only the callback is actually
> implemented, so that I can see what Winrad receives and possibly understand
> why the error happens.
>
Thanks for the offer but:
I realized that I use Winrad 1.4, not 1.3
I am almost sure that when I do the callback I do not reach Winrad but raise an
exception.
I think it has to do with the way I declared the callback function.
I solved the problem by going to C++.
You retired from Winrad and are working on a new project which I am sure is a
lot more exciting.
Regarding the newer versions of Winrad: I cannot find what is new in 1.4 versus
1.3.
There seems to be a Yahoo group but do not find it in searching for it.
Exercise for anyone interested in the Delphi problem:
Delphi: type
TIQData = array of SmallInt;
TCallBack = procedure(Cnt: integer; Status: integer;
IQoffs: single; IQdata: TIQData); stdcall;
C++: typedef void _stdcall (*CallBackPtrType)(int, int, float,
short*);
Delphi: CallBackPtr: TCallBack;
C++: CallBackPtrType CallBackPtr;
Delphi: procedure SetCallback(Callback: TCallback); stdcall;
begin
CallBackPtr := CallBack;
end;
exports SetCallback;
C++: void _stdcall _declspec(dllexport)
SetCallback(CallBackPtrType CallBack)
{
CallBackPtr = CallBack;
return;
}
Calling the CallBack function/procedure
Delphi: CallBackPtr(-1, 101, 0, nil);
C++: CallBackPtr(-1, 101, 0, 0);
Thanks for your patience if you read everything.
73 de Jean-Claude PJ2BVU
