Viktor
>I fully endorse your idea. In Harbour we seem to
>like these kind of clean things :)
Clearly visible fact.
<<<
One problem with the clean approach is that the
Windows API is huge and there is really nobody
interested in maintaining a full set of wrappers.
This is huge work and most ppl only need some
specific parts of it.
Regardless, given some rules and frame to this
problem, I think it isn't impossible to manage it.
>>>
Absolutely correct.
<<<
Here I disagree as the Windows API isn't so good (in
fact it's a pretty weak one with a too long history) that
we choose it as the common denominator for all other
GUIs or APIs in general.
>>>
Agreed.
<<<
I understand you. I had similar concept in mind with hbwin.lib,
but not just for GUI, but for everything that is part of the
Windows API (registry, OLE, whatever, quite like hbwhat),
and without making an attempt to make it a multiplatform
compatibility lib at the same time. For convenience, the
Windows only functions may have a stub (returning permanent
error) when compiled for other platforms.
This doesn't mean however that another library couldn't
be built upon hbwin.lib (and others) to create any sort
of multiplatform solution, but IMO it's not the job of hbwin.lib.
To put it shortly: IMO hbwin should be a pure wrapper for
the Windows API and closely Windows API related features,
nothing more, nothing less. It's also important that
64-bit, Unicode and GCC/MSVC/POCC/OW compatibility be
kept here, and some other general code quality considerations
as well, like safe string operations, ANSI comments, and good
source file granularity.
>>>
Well explained.
<<<
Ideally I'd imagine below steps to clean up this situation:
1) Remove hbole.lib.
2) Move WIN_*() from GTWVG to hbwin.lib
3) Move WIN_*() from uhttpd to hbwin.lib
4) Disable hbwhat from mainstream builds (move to
examples) and start to move useful, tested and error-free
parts to hbwin.lib.
5) Further cleanup hbwin.lib (naming, better separation
of API, additional convenience functions and classes).
6) Remove hbwhat.lib altogether.
>>>
I endorse this in toto.
<<<
We should definitely avoid replicating hbwhat, so we
should concentrate on important functions, and implement
them well, instead of implementing everything and losing
track of them.
>>>
A clear vision. I am motivated to adopt this approach.
First part will be : moving WIN_* functions from GTWVG
to HBWIN.
<<<
For future development a very simple rule can be added:
- If someone needs to access a Windows API function
from .prg code, look in hbwin.lib first, if it's there use it,
if not, implement it there using WIN_<winapi_name>()
naming scheme. Easier said than done I guess :) but
why not try it?
>>>
I am sure everybody will obey this rule.
Now the another guideline:
Many functions of WINAPI accept structures as their
parameters. Should we use them to be compatible with
WINAPI exactly or should we use arrays?
Both approaches have merits and demerits.
I personally propose to use STRUCTURES where ever
possible. What group says?
Regards
Pritpal Bedi
--
View this message in context:
http://www.nabble.com/SF.net-SVN%3A-harbour-project%3A-10164--trunk-harbour-tp21821360p21823805.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
