Just build your own DLL its just too easy for anyone to have bothered
maintaining a public one :-)
IIRC to make a C/VB callable DLL you've just got to add a def file to the
DLL project rather than just using __declspec(dllexport).
I'll send you a Lua5 def file directly (off list).
If that does not work, then you should just be able to mark all of the lua
api functions as "__declspec(dllexport) __stdcall" (or pick your favorite
macro like WINAPI). The LUA_API macro should come in handy to keep that
from being tedious.
BTW: OLE Events are easy to manage using VC5 or later, just be sure to make
an ActiveX DLL or OCX project rather than a "plain" win32 DLL project.
-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br]On Behalf Of Isaac Raway
Sent: Friday, January 30, 2004 4:25 PM
To: Lua list
Subject: Re: Lua Use in Visual Basic
Virgil Smith wrote:
On Thursday 29 January 2004 17:31, Virgil Smith wrote:
As Jamie said calling into Lua should be very simple through a DLL.
Probably your difficult bits will be having Lua call you when scripts
call
functions you've registered cause metamethod invocations etc. Without
putting a lot of thought into it I'd expect that you're going to want to
make an OLE DLL or OCX and trigger OLE events to handle "callbacks from
Lua".
The VB AddressOf operator (added in VB5 IIRC) allows you to take the
address of a function (again as a Long, I think). It works fine with
Windows API callbacks, so it should work with Lua as well.
-- Jamie Webb
Nope, that will blow up your stack (unless you change the Lua sources).
VB uses the __stdcall calling convention.
Win32 Callback functions (designated by the macro "CALLBACK" in the VC
supplied headers), use the __stdcall calling convention as well. The Lua
sources use __cdecl (that's the default/standard C calling convention).
__stdcall and __cdecl differ in stack cleanup strategy so mixing them is a
Bad Idea (tm).
You could of course change the Lua sources in the DLL used by VB so that
they use the __stdcall calling convention, but be sure to be thurough about
it if you do.
Also, handling the callbacks directly like this will give you lots of
headaches while debugging under VB (at least version 6 or earlier, I have
no
experience with the later ones).
That's sort of bad then. I was hoping I could write a DLL to talk to Lua
without having to dive into my own C DLL...it just adds another layer to
the system. I'd change the call methods, but then I'd have to do that
for every release of Lua. Doesn't sound like too much fun.
Also, if what you say about __cdecl and __stdcall is true, then how can
I call the DLL at all in VB? It must be figuring out what convention the
DLL is using I suppose, which the Lua DLL won't do when it calls the
pointer I give it from AddressOf.
Dang. I don't know anything about firing events in a C DLL...looks like
I have some reading up for me?
Oh, also, I can't seem to get a Lua DLL. I've found plenty of Windows
distros, but they are all EXEs without external DLLs. Any thoughts?
~ Isaac
