Hello Przemek and All,
Przemyslaw Czerpak-2 wrote:
>
> In summary I guess that you wanted to make sth like:
>
> if( lOleError == S_OK )
> lOleError = CoCreateInstance( HB_ID_REF( ClassID ), NULL,
> CLSCTX_SERVER, fIID ? HB_ID_REF( iid ) : HB_ID_REF( IID_IDispatch ), (
> void** ) ( void * ) &pDisp );
> }
> + else if( ISNUM( 1 ) )
> + {
> + pDisp = ( IDispatch * ) ( HB_PTRDIFF ) hb_parnint( 1 );
> +#if HB_OLE_C_API
> + lOleError = ( HRESULT ) pDisp->lpVtbl->AddRef( pDisp );
> +#else
> + lOleError = ( HRESULT ) pDisp->AddRef();
> +#endif
> + }
> else
> lOleError = CO_E_CLASSSTRING;
> hb_setOleError( lOleError );
>
> but there is a question if we want to still tolerate code with
> C pointer <-> HVM number item conversions and keep workarounds
> for it. I'm leaving the decision to Mindaugas.
>
Yes, exactly. But I posted a very primitive and dirty way just
to flareup this issue. IMO very important as per new scenario.
>> I cannot test it because I cannot even compile with new SVN.
>
> What's the exact problem?
>
No, you misunderstood me. hbwin.lib ( as of now ) compiles fine
but I cannot use it for missine ole features as my applications are
heavily dependant on above funtionality as I use a lot of Active-X's
and now it is impossible to test code at all.
Viktor can you restore previous hbole and hbwin until we find
the complete compatibility at least on syntax level just to test
my code with new implementation.
Toe was wrong when he split hbwin but I cannot understand
why did you took the similar approach and broke all the compatibility.
Regards
Pritpal Bedi
--
View this message in context:
http://www.nabble.com/Errors-with-11032-tp23521549p23540779.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
