Hi Alexander,
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 ).
That's exactly the idea. The other option is to use
classic (extension-less) code which works the same in both
Harbour and xhb (and even CA-Cl*pper, and most probably other
dialects too). The goal here is to be quite strictly C5.x
compatible, so that is always an option, and probably the
least common denominator for all dialects.
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.
Wouldn't this work ?:
#ifdef __XHARBOUR__
#include "xrddleto.h"
#else
#include "rddleto.h"
#endif
I understand and agree that such kind of changes is unavoidable and
suggest the following:
1) Introduce a [x]Harbour internal version number, at least, at C
level for to be possible to use constructions like
#if HARBOUR_VERSION >= 188
and increment this number after every change, which may require
changes in 3-rd party code ( not 3-rd party only, end applications,
too ).
I think we already have that on Harbour level, where
__HARBOUR__ will return you a number. We could consider
using the SVN repository revision number instead of the
current value, so that it's automatically incremented after
each commit. This would require no coordination or attention
from our part, and could be usable for such a purpose.
On the C level we need to implement this though.
2) Try to do such changes together with other changes of this type
for to have too much version numbers.
Yes. (also see SVN rev no as a number)
3) Create a special log in [x]Harbour repository for such changes -
for people could know what they need to correct and don't spend hours
looking the root of a problem.
I used to mark these in my projects with an "@@" before the
log entry signaling an "incompatible" change, requiring some
3rd party action, like:
* source/rtl/file.c
@@* Change the way blah() works. INCOMPATIBLE, reasons,
description, action to be done.
Anything like this, or simply adding "INCOMPATIBILITY" to
the changelog entry can be a solution (but this one is
easier to mistype and not found by simple search/grep).
4) It would be nice to introduce such version number and appropriate
pp possibilities on Harbour level, too.
We have it:
? __HARBOUR__
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.
Yes it's definitely something to be constantly dealt with in every
Clipper implementations.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
