Hi Maurizio,
not at all.
My target is strong encapsulation of data and methods in class
implementation and i can obtain this, IMHO, only having in the same
source
the (x)harbour and C code. Otherwise the static function, i think
obviously,
will remain local to C module and cannot be reached by xBase code.
In the hwgui CVS repository you can find source/hanimat.prg and take
a look
to what i'm meaning. This code works in xHarbour but in Harbour
(stable
version) don't resolves the HB_STATIC_FUNC correctly giving error at
compile
time.
Notice that amongst the 7 files using "inline" C,
hanimat.prg is the only one actually using STATIC,
and all those functions have distinct global names
anyway, so IMO the whole problem is quite marginal
and academic. The only "upside" is that you can work
in one file instead of two when developing, but
with the cost of creating non-portable code. I'm
not sure if it's worth it.
If speed is critical, or the whole functionality
is in C anyway, you may also consider moving the
whole class to C level. (errorapi.c is an example
for such solution in Harbour). But in the case
of ANIMATE_*() I think it's by itself useful to
have access to the API in a non-OOP way, too.
This is the "inline" C list in hwgui/source:
barcode.prg:947:HB_FUNC( RICH_RECTANGLE )
barcode.prg:958:HB_FUNC( RICH_CREATEPEN )
barcode.prg:968:HB_FUNC( RICH_SELECTOBJECT )
barcode.prg:975:HB_FUNC( RICH_CREATESOLIDBRUSH )
hanimat.prg:116:HB_FUNC_STATIC ( ANIMATE_CREATE )
hanimat.prg:125:HB_FUNC_STATIC ( ANIMATE_OPEN )
hanimat.prg:130:HB_FUNC_STATIC ( ANIMATE_PLAY )
hanimat.prg:135:HB_FUNC_STATIC ( ANIMATE_SEEK )
hanimat.prg:140:HB_FUNC_STATIC ( ANIMATE_STOP )
hanimat.prg:145:HB_FUNC_STATIC ( ANIMATE_CLOSE )
hanimat.prg:150:HB_FUNC_STATIC ( ANIMATE_DESTROY )
hanimat.prg:155:HB_FUNC_STATIC ( ANIMATE_OPENEX )
hcombo.prg:35:HB_FUNC(COPYDATA)
hcontrol.prg:614: if hb_inline( lParam) { LPARAM l = (LPARAM)
hb_parnl( 1 ); hb_retl( l & 0x40000000);}
hcontrol.prg:870: if hb_inline(uStyleTmp) { ULONG ulStyle =
(ULONG)hb_parnl( 1 ) ; hb_retl( ulStyle & BS_MULTILINE ); }
hcontrol.prg:1251:HB_FUNC_STATIC( TACTIVEX___ERROR )
hcontrol.prg:1298:HB_FUNC_STATIC( INITACTIVEX ) // hWnd, cProgId ->
hActiveXWnd
hcontrol.prg:1315:HB_FUNC( ATLAXGETDISP ) // hWnd -> pDisp
hmonthc.prg:133:HB_FUNC ( INITMONTHCALENDAR )
hmonthc.prg:155:HB_FUNC ( SETMONTHCALENDARDATE ) // adaptation of
function SetDatePicker of file Control.c
hmonthc.prg:184:HB_FUNC ( GETMONTHCALENDARDATE ) // adaptation of
function GetDatePicker of file Control.c
htrackbr.prg:152:HB_FUNC ( INITTRACKBAR )
htrackbr.prg:171:HB_FUNC ( TRACKBARSETRANGE )
printdos.prg:615:HB_FUNC( AFILLTEXT )
Brgds,
Viktor
Best regards.
Maurizio
-----Messaggio originale-----
Da: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Per conto di
Massimo Belgrano
Inviato: giovedì 5 giugno 2008 23.54
A: Harbour Project Main Developer List.
Oggetto: RE: [Harbour] HB_STATIC_FUNC
Hi Maurizio
Your problem in hwgui will be resolved isolating c code in
external *.C ?
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Szakáts Viktor
Sent: Thursday, June 05, 2008 7:46 PM
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] HB_STATIC_FUNC
I'd add one more problem with INLINE C code:
I extensively use grep for Harbour and my own projects
too, it's a very powerful tool to locate stuff in the
source.
When I'm looking for C code parts (function names
let's say), naturally I search through *.c files only.
Problem: C code may be hiding inside .prg, too, or
even in .ch. This results in either wrong code updates,
decisions, or in the best, case another pass of grep.
Not to mention all the tools which rightly except
some kind of content in a given file type (most
obvious example is syntax coloring).
So this is IMO just one more thing that makes development
more complicated and error prone, without much gain.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
