Posted by: yoyo
« 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.
News:
Thank you for using this forum as the technical support base for your device.
● You can format the text and attach screenshots, photos and RDS Spy records
● Faster reply: 50 % of questions are answered within 30 minutes
● You don't need to register (but registration is possible)
● The members represent a wide range of experts
● The resolution will be helpful for other users
● You'll be notified by email about new post
Posted by: SteveyD
« 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"
I'm not familiar with Clarion,
For Visual Basic, C# etc, you need to declare the Receive routine as "UNSAFE"
Posted by: yoyo
« 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...
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...
Posted by: Jan
« 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?
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;Posted by: yoyo
« 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
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