On 29 April 2014 20:54, Markus Fritsche <mfritsche@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 <mfritsche@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.