Author Topic: mRDSio.dll Prototypes  (Read 3751 times)

yoyo

  • Newbie
  • *
  • Posts: 7
mRDSio.dll Prototypes
« on: May 24, 2012, 04:12:43 pm »
I've been having good success using the mRDSio.dll for sending commands using Clarion, but have had no luck getting the Receive function to work.  From searching around, I can see other developers have been having the same issue in other languages as well.   I believe it's because of the return type.

I know from previous experience that the various languages all have a different spin on returning complex types; that's why the Windows API avoids it for the most part.

It would be great to have an overloaded Receive function that is more like the Send function.  In other words, the Delphi prototype would look like:

function Receive(Adr, Len: Integer; Data: TData): boolean; stdcall;

By including TData in the parameter list, passed by address, the issues associated with complex return types is avoided.  I'm thinking you could keep the Receive function you have now, for backwards compatibility, and add the one above to make the dll a little more compatible across different programming environments...

Any chance?

-Brian


Jan

  • Hero Member
  • *****
  • Posts: 564
Re: mRDSio.dll Prototypes
« Reply #1 on: May 24, 2012, 06:07:26 pm »
I'm open to making any change that would make your work simpler. However I don't think your suggestion will help. In this function, the Data are output, not input parameter.

If passing complex variable makes problems, what about passing a pointer only?

Code: [Select]
type PData = ^TData;
...
function ReceiveP(Adr, Len: Integer; OutputData: PData): boolean; stdcall;

yoyo

  • Newbie
  • *
  • Posts: 7
Re: mRDSio.dll Prototypes
« Reply #2 on: May 24, 2012, 06:17:25 pm »
I'm not familiar with Delphi, but most languages have the ability to pass parameters by address; which is what I'm suggesting for the Receive function. 

So, even though it is a function parameter, because it is passed by address, it essentially functions as an input/output parameter.  When the Receive function populates it, and returns, the caller has access to the parameter.

Right now, the Send function is actually passing TData by address; as that's how I'm prototyping it and it works fine...

Returning a pointer should work as well, but would still require a parameter passed by address that would indicate it's returned length....  I was thinking having TData in the parameter list passed by address is a somewhat more standard way of handling it...

SteveyD

  • Newbie
  • *
  • Posts: 24
Re: mRDSio.dll Prototypes
« Reply #3 on: June 10, 2012, 05:19:19 am »
yoyo

I'm not familiar with Clarion,

For Visual Basic, C#  etc,  you need to declare the Receive routine as "UNSAFE"

yoyo

  • Newbie
  • *
  • Posts: 7
Re: mRDSio.dll Prototypes
« Reply #4 on: June 11, 2012, 06:11:36 pm »
No big deal if you don't want to do it.  For what I'm doing, I only need uni-directional communication anyways.