Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Skipped Methods in generated Code

I want to generate Code (CrossTak 2.0.27, licenced) from a .Net-Dll for my Delphi application (Delphi Tokyo 10.2). After I have generated the Code, serveral methods are missing.
The report which is shown after the code was generated says that methods were skipped. For example: "Method: getTest, skipping, Parameter Type,DateTime&".
Can anybody tell what I'm doing wrong?

Thank you very much!

Best regards

Can you show me the .NET declaration of getTest either from reflector or source?

Basically CT can't do every type but does about 85% of things. It looks like there is a DateTime ref argument which is not a simple type. Ref arguments are supported but on simple types.

You can get around this by writing a simple wrapper and consuming that.
Hi kudzu,

Thank you for your reply. I will list up some functions which aren't generated:

1. public SPXRFTest. eRFTESTStatus getTermRTC(ref DateTime rtc)
2. public SPXRFTest. eRFTESTStatus getTermBatteryStatus(ref ushort VBattAct,ref ushort VBattMin,ref ushort VBattMax,ref SPXRFTest. eBattStatus VBattStat)

Parameter info:

rtc: System.DateTime

VBattAct: System.UInt16
VBattMin: System.UInt16
VBattMaxm: System.UInt16
VBattStat SPX_RFTEST.SPXRFTest.eBattStatus -> public enum eBattStatus (simple byte) -> this type was generated by CT

I for example have a function with similar parameters like "public SPXRFTest. eRFTESTStatus setTermRTC(DateTime rtc)", but this function was generated.

I tried to implement function 1 and 2 on my own, but I don't know the Parameter "aMethodID" for the function:

class function MethodCall(aObj: TObject; aClassName: string; aMethodName: string;aMethodID: Int32; aParams: TCTStreamWriter = nil): TCallRight;

The wrapper you mentioned...Can I write it without having access to the sourcecode of the DLL? Would you like to give me an example, if you are ok with that?
ref DateTime is not supported, but IIRC DateTime is (would need to look).

The normal work around is to make a simple proxy/wrapper class which returns DateTime as a result.

The second one at least makes more sense because there are multiple return values, but it would be a better design to return a class with all the values, and that is how I would suggest to wrap it as well.

Based on what I see I'm guessing the .NET library is wrapping a C/C++ library, or is written by a C/C++ developer. This API isn't within what I would consider ".NET norms" for an API.

Regarding the second case.

ref UInt16 is supported. Enums are transformed to bytes and it should generate constants in the .pas file for you to use.

Regarding the wrapper - Thats not quite what I meant. Instead of that, its much simpler.

1) Using VS, VS code or other make a C# (or other) project which connects to the target assembly which is giving you trouble.

2) Expose a new API which proxies the calls. For example, MyWrapper.GetTermRTC: DateTime or even string and if exception, throw it instead of returning it as a value. Or, return 2 values if you want to handle it that way. But CrossTalk will pass exceptions properly and that is the normal way to handle such in both .NET and Delphi.

3) Use CrossTalk to consume your wrapper which is "friendlier" both in terms of CrossTalk, but also more to the .NET norms and guidelines as well.

Forum Jump:

Users browsing this thread: 1 Guest(s)