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