If we start extending the API in this hidden way,
we will end up with same problems as with Clipper
API: Two way portability is lost.
You are absolutely right. But as I could not find
the appropriate methods for the job so I used this
trick. I do not want to extend anything. It will be set right
after some real Xbase++ user reports how it is achieved
in Xbase++. Till then it remains documented here.
BTW this does not break Xbase++ code at all.
If supplied like as I described will be honored otherwise
ignored.
It breaks it in the reverse direction. Code written for
hbxbp won't run under Xbase++. (== two way compatibility
is broken)
So IMO we should document this in any case. Such extra
documentation cannot hurt, and you can save lot of
head-scratching in the future (also for users and other
developers, also documenters) if such differences
are documented in the code, rather than scattered in
ChangeLog entries.
One more fundamental difference will be "Resources" which
considerably differ from any WIndows implementation. We
have to document these differences or a way to map them
to QT standards.
That's right.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
