On Sat, Jan 23, 2016 at 2:18 PM, R Smith <rsmith at rsweb.co.za> wrote:
> > > On 2016/01/23 9:41 PM, Bart Smissaert wrote: > >> Using a .tlb file to access the sqlite3 functions from VB6. >> Sofar when the arguments of the sqlite3 function are declared as int I >> have >> been using >> long in the IDL source to compile the tlb and this has been fine. >> > > I'm not very familiar with the calling conventions and type declarations > in VB6 - but if Long is the same as Int in bit-length and order, and the > prototype parameter order and calling convention is the same as in C, then > the types should match 100% all the time. If it isn't, then the fact that > it has been working "fine" up to now is an accident of chance and not a > good design choice. >From what I can find online, in VB6 byte is 8 bit, int is 16 bit, long is 32 bit (probably to be backward compatible with DOS era BASIC datatypes). So long would be the right type for use with the SQLite API. > sqlite3_compileoption_get is defined like this: >> >> const char *sqlite3_compileoption_get(int N); >> >> but using long here for the N argument causes a problem and it took me a >> while >> to unravel this problem. The .tlb compiles fine and all shows fine in the >> object browser >> in VB6, but the ActiveX can't be registered with Windows. >> The solution was to use int or byte instead in the IDL for the N argument: >> > > It might be that in VB "Long" means 32 bits or 64 bits of Integer and may > or may not support a sign bit (As I said, I don't know VB well), but I will > be shocked if "Byte" in any language ends up meaning 32-bit signed integer > (as I assume *Int* refers to in the C code you mention). > > I can't believe this solution is the right one, I feel like it "works" > only by some jiggery-pokery from the compiler that was intended to > smooth-over some other conversion or such. > > If it ain't the right solution, then the rest of your question is moot and > my advice would be to first find the true bit-level matching type for c's > int in VB, if however it /IS/ the right solution, my best advice would be > to move away from VB and find a real programming environment (but I doubt > this is the case). I suspect it works because whether you push 8 or 16 or 32 bits on the stack for a 32 bit process, it's always going to be 32 bits for alignment reasons. My guess (having only the most cursory of familiarity with IDL and VB6) is that there is some calling convention issue. The @4 suffix on the function name usually means that the function is STDCALL and that the callee will clean up the stack. If for some reason both the caller and callee cleaned up the stack for this function, that would definitely be a problem. -- Scott Robison
