On Thu, 05 Feb 2009, Szak�ts Viktor wrote:

Hi Viktor,

> We should IMO never include windows.h from hbdefs.h. Besides
> slowing down build time to a great deal, we don't do this for other
> OS APIs either. This would also suggest that Windows API usage
> is freely allowed in any files, which counteracts with our effort to
> create portable code in the first place. Most of our core files don't
> need windows.h.

I do not agree.
And now I have very good example.
In xHarbour there is serious bug related to this subject.
Today I lost few hours to locate it. The problem can be observed
in SORT ON ... command but not only. Now I think that I know the
answer for some other bug reports though without any code watching
for them.
Let's give some days to xharbour team to check how much time is
necessary to locate the source of such problem and fixing it. It's
possible to fix the problem even without knowing the reason and it
will be also interesting to see how it will be resolved.
It should give the real life answer if you are right or not and how
much developers time can it cost.
You can also try to locate it. Below is self contain example Enrico
sent to me.

best regards,
Przemek



FUNCTION MAIN()

    Local aStru:={{'aa','C',3,0},;
                  {'bb','C',3,0}}
    ? version()
    DbCreate('testxxx',aStru)
    Use testxxx Exclusive New

    Append Blank
    Replace aa With 'xxx'
    Replace bb With 'xxx'

    Append Blank
    Replace aa With 'ggg'
    Replace bb With 'ggg'

    Append Blank
    Replace aa With 'kkk'
    Replace bb With 'kkk'

    ? "Sorting..."
    Sort On aa To testxxx1
    ? "Done"

    RETURN NIL
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to