On 29 April 2014 20:54, Markus Fritsche <mfrits...@reauktion.de> wrote:
> Hello Igor, > > I did change my class (tbh, I was just looking at the Cairo stuff and > did some cargo cult programming). > > NBFFICallout new resolveType: #TM1U prints TM1U > > NBFFICallout new resolveType: #TM1P prints TM1P > > - my DoIt still gives NBExternalType > > I attached the resulting CompiledMethod as a fuel serialized file. > > What can I look at more deeply? > > i don't know what is going on.. everything looks correct.. as a workaround, you can change the return type of offending call to return uint, and then you can manually convert it to instance of TM1P with corresponding handle value. Also, i doubt it, but try change the alignment NativeBoostWin32>>stackAlignment to use 16 P.S. the fuel file with compiled method is not really helpful - it gives me an error during materialization. > Thank you for your patience, > Markus > > On 29.04.2014 00:36, Igor Stasenko wrote: > > Object subclass: #TM1U > > uses: TTM1ApiLibrary > > instanceVariableNames: 'handle' > > classVariableNames: '' > > poolDictionaries: '' > > category: 'Cognos-TM1-Api' > > > > hmm.. why just don't subclass from NBExternalObject? > > If you don't need to subclass from own base class, you can just subclass > > from > > NBExternalObject, which means you already having handle ivar, and > > #asNBExternalType: inherited at class side, tested and working..? > > > > > > So, try > > > > NBFFICallout new resolveType: #TM1U > > > > what it gives? > > > > On 28 April 2014 23:44, Markus Fritsche <mfrits...@reauktion.de> wrote: > > > >> > >> On 28.04.2014 13:30, Igor Stasenko wrote: > >>> This is strange.. should work fine. There's no way how > >>> NBExternalObjectType could return an instance of NBExternalHandle. > >>> Please check your code again. > >> Been there, done that => thrown everything away and restarted the code > >> from scratch... Sourcecode attached (the 32bit libraries are in the bin > >> subdirectory, there's another bin64 directory) - is there anything > >> obvious wrong with it?. > >> > >> Workspace: > >> ==================== > >> TM1LibraryLoader loadTM1Library. > >> > >> TM1Library tm1APIInitialize. > >> hUser := TM1Library tm1SystemOpen. > >> hPool1 := hUser tm1ValPoolCreate. > >> hPool1 inspect. > >> hUser tm1SystemClose. > >> TM1Library tm1APIFinalize. > >> ==================== > >> > >> The Inspector I get shows > >> NBExternalHandle > >> self @ 16r74CF4A8 > >> (apparently it's fine for TM1U, otherwise tm1ValPoolCreate wouldn't be > >> found) > >> > >> could it be inspector screwed? > > what > > hPool1 class > > gives? > > > > > >> From the headers: > >> > >> #define TM1API __stdcall > >> #ifndef TM1IMPORT > >> #define TM1IMPORT __declspec( dllimport ) > >> #endif > >> > >> typedef void * TM1U; // user handle > >> typedef void * TM1P; // pool handle > >> TM1IMPORT void TM1API TM1APIInitialize( void ); > >> TM1IMPORT TM1U TM1API TM1SystemOpen( void ); > >> TM1IMPORT TM1P TM1API TM1ValPoolCreate( TM1U hUser ); > >> > >> > > i don't see where you are using stdcall calling convention option? > > you should specify it either in code: > > > > self nbCallout > > stdCall > > function: #( TM1U TM1SystemOpen( ) ) module: > > > > or in the class with callout, implementing > > > > ffiCalloutOptions > > ^ #( + optStdcall ) > > > > (i think you can just put it into trait) > > > > > >> In order to debug further I will have to redo the Windows VM. > >> > > > > > > > -- Best regards, Igor Stasenko.
