Clarion.NET/Clarion Win32 Interop

c10
clarionnet
Tags: #<Tag:0x00007f60c08ad1f8> #<Tag:0x00007f60c08acfa0>

#1

I’ve heard bits and pieces of information that there is an easy process to calling code written in Clarion.NET in Clarion 10 Win32 applications, but haven’t been able to find anything substantial on it. Does anyone have experience with this, and is there any advantage to writing a component in Clarion.NET instead of C#? Does calling code from Clarion.NET still require the use of ActiveX as it would with C#? Obviously I’m not looking to create anything substantial in Clarion.NET due to the incomplete and fleeting nature of the product, but if it’s possible to create small components that can easily and safely be called from a Clarion Win32 app, that’s something I would be very interested in.


#2

You’re much better off using C# for this.

Clarion.NET does have this ‘feature’ but it’s basically a reworking of a technique that was originated by Robert Giesecke a decade ago.

https://sites.google.com/site/robertgiesecke/Home/uploads/unmanagedexports

Robert Giesecke called it DllExport - the same feature reworked for Clarion.NET was call ExportDll

The original DllExport is still available (see above link) as is a newer continuation of that on GitHub

Graham


#3

If you haven’t seen this article on ClarionHub, it is quite useful.
https://clarionhub.com/t/using-groups-with-net-com-controls-part-2/313


#4

Thanks for the responses Rick and Graham, that’s very helpful. I guess I’ll get a bit more specific about what it is I’m trying to accomplish. I’m looking into the feasibility of creating a Data Access Layer in .NET to replace the Clarion FILE, DRIVER model. I’ve heard it’s possible and has been done before, but like many things in the Clarion world there’s no easily discoverable resources on where one would get started with something like that.


#5

To access what type of data?


#6

Databases, specifically we’re using MSSQL right now. Researching every possibility of overcoming the well known Clarion SQL driver limitations (error 37, cursors) without basically having to rewrite the entire application. Three possibilities I’m looking at right now

  1. Using the IP driver as a “proxy” to eliminate direct access to the database from the application.
  2. MAV Direct ODBC (a fun couple of months tracking down the original developer and figuring out how to transfer money to Russia without being put on a terrorist watch list).
  3. Utilizing a DAL written in .NET, which is the purpose of this thread.

#7

Did you watch this webinar:


#8

Wow, I have not seen this! Thank you so much for sharing, this appears to be exactly what I’m looking for!