Creating a wrapper for an existing dll

[keyless]

I'm having some trouble getting my head around using existing .dll libraries with Rev (as external, not using VBscript). Building external info is farely scattered around and seems dated, but I've gathered what I can, but most seems to be about building a new external. I'm more interested in a wrapper/API concept.

For example, say I would like to use the Bass.dll audio library http://www.un4seen.com/ . I use this as an example, because there seem to be a number of API's written for this, from PureBasic to .Net, and it even comes with a C++ API.

How would one go about creating a rev wrapper for Bass.dll?

[ukimiku]

I am very new to the dll for Runrev business, but the first thing that came to my mind was that if you can obtain the source somehow, recompile it with the dll skeleton provided by the ExternalEnvironmentV3 from the tutorial. Then you should have your wrapper in place. Or it might be worth looking at the glue code provided with the example dll tutorial.

Regards

[BarrySumpter]

Hi all,

I'd like to create a wrapper for an existing dll as well.
Its been 18 months since the previous reply.

Has anyone gotten any further?

I don't have the source to the .dll nor do I want it.
Nor any doco.
Far too much research and trial and error
so far its been a complete bust
trying to get LiveCode to shell to a .exe that uses the .dll.

I have a .dll and I have a vb.net .aspx app that uses it successfully.

Is there a way to use this .dll in LiveCode?

Something like:
Start Using External ("C:\MyApp.dll")

[BvG]

You need a windows C++/C# programmer. He'd probably be able to implement a wrapper for a specific DLL in few workhours, most of them spent on understanding how LC externals work. Of course, most people here are not that kind of programmer, so all I can suggest is to ask for this service on another forum.

Note that a general DLL accessing external is probably very hard to do, even when only targeting a specific subset of DLLs. That is because each DLL has its own type of interface, protocols and data types and nothing is normed. It'd be hell to cater to all of them, even ignoring those that do take over screen redraws or change hardware, os calls or drivers etc.

[mwieder]

Barry- if you have an aspx page that works with the dll, then there's almost no doubt that the dll is a COM component. In that case you'll need to create an external .exe program to talk to it. Once you have that, you can use the shell command to communicate with the dll. That's how I work with COM components - I wrote an interface to QuickBooks that way, and it's been working fine for quite some time.

But you *do* need the documentation and you *do* need to write a glue program to do this. Sorry to tell you that you have to do some work, but that's what programming's all about, no?

[BarrySumpter]

Thanks for the replys everyone.

I've read thru the doco on using the source for an external and getting it to work with LiveCode.

Its over the top rediculously convoluted and complicated.

Might as well just leave it in its native language.
And find a work around. Which is what I've done.

It does come with a .exe wrapper that I've been able to use in
VB, VB.Net, LiveCode Desktop, and .Aspx with the shell command.

But the .exe shell command in LiveCode Scripting Server can't handle it for some reason.
Or its my implementation of LiveCode Scripting Server on IIS 5.1.
Although LiveCodc Scripting Server on IIS 5.1 does shell to other .exe without fail.

Thanks again

[mwieder]

IIS is really protective of what it will allow to run as an executable. I did a writeup on this a while back, I'll have to dig around for it. From memory, you may have to stick the executable into a protected directory, maybe into cgi-bin.

[mwieder]

Well, I still can't say I recommend doing anything with IIS, but if you've got an executable that needs .NET I guess you're stuck with it. Here's the writeup I did a while back for the older cgi server, but all the permissions stuff should still be similar.

http://article.gmane.org/gmane.comp.ide ... /match=iis

I wrote this originally because nobody was sure whether it could be done, so I took that as a personal challenge. Thankfully it's been quite a while since I've had to do anything with IIS.

[BarrySumpter]

Thanks Mark,
The first paragraphs already got me giggling.

[BarrySumpter]

...
The important thing is that you DON'T create this directory under the /inetpub directory
...

Man, If I could swear on this forum ...
Testing now ...

[BarrySumpter]

Farkel!

Got it working now.

Doesn't matter if the physical virtual folder is under the iNetPub folder or not.

Trying to shell witn LiveCode Scripting Server on IIS 5.1
For MyApp.exe
1) Everything has to be with in one of the folder that IIS knows about.
( Althogh I could execute every other .exe I could find, MyApp.exe would NOT execute unless on an IIS folder.)

2) MyApp.exe uses a MyApp.dll
When MyApp.exe is on the wwwroot - MyApp.dll had to be in wwwroot
Or instead of wwwroot MyApp.exe and MyApp.dll had to be together in a IIS virtural folder.
(it would NOT execute properly if the MyApp.dll was in a sub-folder 'bin' or anywhere else in a sub folder)
So the .exe is looking for the .dll on the same folder as the .exe.

3) Since MyApp.exe needed to write an xml (text) file to a folder
(usually where MyApp.exe is)
I had to set the defaultFolder in LiveCode to a folder IIS knows about
Both wwwroot and an IIS virtual folder worked properly.

If I tried "c:\" I receved a permissions error.
Because I had NOT set the C:\ root folder in IIS as a virtural folder.

Code: Select all

...
set the defaultFolder to "M:\MyVirtual_IIS_CGIBinFolder\"
...