Thank you very much Przemek, I'll implement this. I don't
like such hacks and buggy 3rd party code either (they also
ruin the quality image of Harbour). The sole reason we have
legacy*.[c|prg] is to help users to transition to our
proper/better interfaces and provide the old interfaces for
them until this process finishes. I understand this may need
time in some situations because such changes may have
implications on final user code, documented upstream API
interfaces, etc. [ BTW personally I don't need any such
legacy interfaces. ]
Anyhow, the goal is to have these code parts disappear rather
sooner than later.
Question is: Should I mark these legacy parts with HB_LEGACY_LEVEL2?
(this way they'll disappear in next major release)
Brgds,
Viktor
On 2009.08.19., at 10:01, Przemyslaw Czerpak wrote:
On Wed, 19 Aug 2009, Szak�ts Viktor wrote:
Hi Viktor,
My proposed changes with your fix to use hb_parnint() are working
fine :-)
So we just need this call in legacy.prg:
IF ISNUMBER( xOle )
xOle := __OLEPDISP( xOle )
ENDIF
and add this function to olecore.c:
HB_FUNC( __OLEPDISP )
{
IDispatch* pDisp = ( IDispatch * ) hb_parnint( 1 );
IDispatch** ppDisp;
ppDisp = ( IDispatch** ) hb_gcAlloc( sizeof( IDispatch* ),
hb_ole_destructor );
*ppDisp = pDisp;
hb_retptrGC( ppDisp );
}
Nice.
this way we keep backwards compatibility with previous Harbour
OleAuto
code and also we are compatible with xHarbour :-)
If you are so kind to upload it to the SVN then we can tell our FWH
users to download and use the official Harbour builds instead of
having to provide a modified build of our own. Thanks,
Okay. I'll do only one modification, __OLEPDISP() will be put in
legacyc.c, plus I may rename it. I'll do this tomorrow.
Personally I do not like hacks used to keep alive wrong 3-rd party
code or for compatibility with xHarbour when other code should be
fixed.
But if you want to add it then few notes about it.
You cannot add above function to legacyc.c because hb_ole_destructor
is intentionally static function so it can be only part of olecore.c.
We have public C function hb_oleItemPut() which allows to create
at C level Harbour OLE pointer items. It's not necessary to use
numbers
by core or 3-rd party code can use this function. If some code still
uses numbers then it's a bug in this code which should be fixed
instead
of adding workarounds for 3-rd party bugs to Harbour SVN.
Anyhow if you want to add it as some type of legacy code which will be
removed in the future but now gives time to users and 3-rd party
developers
to fix their code then simply use public API to create such function
in legacyc.c, i.e.:
#include "hbwinole.h"
HB_FUNC( __OLEPDISP )
{
hb_oleItemPut( hb_param( -1, HB_IT_ANY ),
( IDispatch * ) ( HB_PTRUINT ) hb_parnint( 1 ) );
}
I only hope that when we remove the legacy code the problem will not
return.
best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
