-Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Andi Jahja
> Sent: Saturday, May 31, 2008 8:17 AM
> To: 'xHarbour-Developers'
> Subject: Re: [xHarbour-developers] Problem with Andi's ace32.c approach
>
> Brian:
>
>
Brian:
> When I discussed this issue with Ron, he was of the opinion that
> this module could be auto-generated from the DLL itself, thus
> eliminating the maintenance issues in pursuing things like this.
I supposed you are referring to ace32.lib to be linked. Yes, of course,
it was what it used
08 6:40 AM
> To: Xharbour-Developers
> Subject: Re: [xHarbour-developers] Problem with Andi's ace32.c approach
>
> Luis and All:
>
> It's a known issue with Borland, but _not_ with all other compilers.
> I would suggest that those who have bought ADS to enquire ADS/Sybase
Luis and All:
It's a known issue with Borland, but _not_ with all other compilers.
I would suggest that those who have bought ADS to enquire ADS/Sybase on
this matter. FYI, what I did is based on documented reference, ace.h.
There we can find prototypes and variable definition/typedefs
implemented
Ron, all:
I apologize for the long message but there's some important
issues that need to be solved.
We've found a problem with Andi's approach of using ace32.c
he coded instead of the previous Implib approach for ace32.dll.
We're currently building our app with v 8.1 dlls. One of the
test fold
5 matches
Mail list logo