> The commonest problem is the calling convention. sqlite3.dll is compiled from the amalgation with std_call calling convention (/Gz flag). All the SQLite functions are called with _stdcall from the .tlb, so the IDL source has that for every function. You didn't mention it but how arguments are called from VB6 is also very important, that is ByVal or ByRef. I think that unless the argument is going to be altered I have to pass them always ByVal.
In my VB6 code I had passed the compile index ByRef, so I changed that to ByVal. Now, I can use long in the IDL for sqlite3_compileoption_get and all works fine! There are lots of other places though in my VB6 code where I have passed the arguments ByRef and no problem with those, but will have a good look at this now. I went back to ByRef, unregistered the dll with Windows, recompiled it, but I couldn't reproduce the problem. So it looks it may remain a mystery what happened here, but I learned something and made some progress. RBS On Sun, Jan 24, 2016 at 2:53 AM, <david at andl.org> wrote: > I have been here many times. As I recall the steps interfacing to COM/IDL > are: > > 1. Find out what ACTUAL types and ACTUAL calling convention were used by > the > DLL you are targeting. The C header file declarations are not definitive: > you need to examine the options used to compile the DLL and often the link > map to be sure you know what finished up in the DLL. > > 2. Match the IDL explicitly to the ACTUAL types and ACTUAL calling > convention used. > > The commonest problem is the calling convention. If your DLL is compiled > with STDCALL, you must makes sure to match it; and vice versa. > Unfortunately > with the wrong calling convention is it possible for some calls to work > others not. Even so, this is an odd one. > > I checked the Sqlite source code and there is nothing special about this > function that I can see. > > I didn't receive your original message (dunno why) so I don't know what the > 'problem' was. > > Regards > David M Bennett FACS > > Andl - A New Database Language - andl.org > > -----Original Message----- > From: sqlite-users-bounces at mailinglists.sqlite.org > [mailto:sqlite-users-bounces at mailinglists.sqlite.org] On Behalf Of Bart > Smissaert > Sent: Sunday, 24 January 2016 12:37 PM > To: SQLite mailing list <sqlite-users at mailinglists.sqlite.org> > Subject: Re: [sqlite] Slight problem with sqlite3_compileoption_get > > > That is where you confused me. C also has a long type! > Yes, that is why I said IDL long. > > > File byte under "lucky" above. > > OK, I can see that and replaced that with int. > What is different though about sqlite3_compileoption_get, so that long in > the IDL causes the mentioned problems and int doesn't? > > RBS > > > > On Sun, Jan 24, 2016 at 1:11 AM, Roger Binns <rogerb at rogerbinns.com> > wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 23/01/16 13:14, Bart Smissaert wrote: > > >> I am somewhat confused about what you wrote. > > > > > > This has to do with making a .tlb (type library) to access > > > sqlite3.dll from a VB6 ActiveX dll. > > > > That much was clear. > > > > > Sofar I have mapped SQLite int with IDL long ... > > > > That is where you confused me. C also has a long type! The C long > > type will either be the same size as C int, or bigger[1]. Windows has > > a long legacy, and that is how you ended up in this situation. On 16 > > bit Windows, int was 16 bits and long 32 bits. On 32 (and 64) bit > > Windows, int and long are both 32 bits. > > > > Because of the 16 bit legacy of Visual Basic, you'll be getting this > > advice about ints and longs and compatibility. On Win32 where SQLite > > says "int" it means a signed 32 bit number. > > > > Note you can get lucky with mismatches. (I won't bore you with > > details about promotion to int, caller vs callee cleanup, how little > > endian helps with the luck). > > > > > .. and that is all working fine, except for > > > sqlite3_compileoption_get. Instead here int or byte works fine. > > > > File byte under "lucky" above. > > > > sqlite3_compileoption definitely takes a 32 bit integer as its only > > parameter. If "long" in your idl also maps to a 32 bit integer, then > > there is something else going on in your diagnosis of "working fine" > > :-) Sadly you'll need to figure that one out. > > > > [1] There are rules about what standards conforming compilers are > > allowed to do, there is practise over what they actually do, the > > implementors of systems do various things (often for historical or > > "compatibility" reasons). This also spills over into ABIs and calling > > conventions (eg exactly how types of parameters and return values are > > passed on certain CPU architectures). The list of considerations go > > on and on. It looks like Keith would be happy to discuss them :-) > > > > Roger > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v2 > > > > iEYEARECAAYFAlakJLQACgkQmOOfHg372QS7SACfboJV/o1apKA3q5UInT5sOY6/ > > NUsAn2UbTS1004P5QnpJGRQcCTASMJaI > > =LMtI > > -----END PGP SIGNATURE----- > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users at mailinglists.sqlite.org > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
