On Sat, 02 Feb 2008, Alexander S.Kresin wrote:
Hi Alexander,
> Hi All,
> it become more and more difficult for 3-rd party products developers
> to fight with differences between Harbour and xHarbour and between
> versions of the same compiler.
> Just a couple of examples.
,-----------------------------------------------------------------------
| > 1) At() - hb_At() issue in Harbour. As a result now we have At() in
| > xHarbour and in official Harbour distribution, which accept 4
| > parameters, At() in new Harbour code, which accepts only 2 and
| > hb_At() in new Harbour, accepting 4 parameters, which is absent in
| > xHarbour and in older Harbour.
| > The only decision I've found to get a code, working with ALL
| > versions, is to duplicate hb_At() with a new name in my code ( HwGUI,
| > Leto db server ).
`-----------------------------------------------------------------------
I dedicate above to anyone who will want to extend standard function
parameters. In longer terms it has to be source of serious troubles.
And this is only half of problem because the code is only for Harbour
and xHarbour. Think what will happen if the code will have to work
with more compilers.
Now I suggest to use HB_AT() and add to your project HB_AT() function
for xHarbour build until xHarbour will not support it.
#ifdef __XHARBOUR__
HB_FUNC( HB_AT ) { HB_FUNC_EXEC( AT ); }
#endif
When it will then you simply remove it.
,-----------------------------------------------------------------------
| > 2) Recently the base workarea structure was changed in xHarbour. You
| > know that every RDD have it's own workarea structure with first
| > fields from a basic and some other, specific for this RDD, after the
| > basic, and this structure is kept in a new header file.
| > Now, if I want to keep the Leto RDD working for both Harbour and
| > xHarbour, it's latest and previous versions, I need to provide two
| > header files and leave a note for users of latest xharbour to rename
| > xrddleto.h to rddleto.h before compiling the RDD.
`-----------------------------------------------------------------------
And this I'd like to dedicate to you ;-)
Such problems happens when API depends too strictly on some memory
structures which are public.
Our RDD API is inherited from Clipper so we cannot change it too
much without introducing additional problems for 3-rd party RDD
developers who are porting their existing Clipper code to Harbour.
Now it's very easy job. But I do not want to repeat such problems
in other places and this is the answer why HB_SOCKET structure is
not public.
[...]
> I ask xHarbour developers, who read this list, to discuss the
> possibility to introduce such a C level version number - for now, at
> least, in hbapirdd.h, something like #define WORKAREA_VERSION NNN, to
> be possible for 3-rd party RDD creators to write in new RDD structure
> definition:
> #ifdef __XHARBOUR__
> #if WORKAREA_VERSION >= NNN
> USHORT uiFieldHidden; /* Total number of fields hidden */
> #endif
> #endif
> It's not my only problem, the same is for other RDD's - Mediator, for
> example.
uiFieldHidden, bFlagCount, uNullFlagField in xHarbour main work area
structure are absolutely not necessary.
It's a side effect of some modification for VFP DBF extensions (NULL and
VARLENGTH fields) still not finished which should be only inside DBFRDD
not in main work area structure what causes that 3-rd party binary RDDs
stopped to be compatible.
We cannot allow to change main RDD structure from which each RDD inherits
for some local RDD extensions which are not usable at all for others.
And in this case they are also not functional yet - it's work in progress.
In summary it seems to be xHarbour only problem and you should ask xHarbour
developers about it.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
