-
ckedem committed revision 12864 to the Harbour SVN repository, changing 2 files.
2009-11-12 11:17:55 UTC in Harbour
-
Gabor,
This bug was fixed at rev11308:
2009-06-11 22:57 UTC+0300 Alexander Kresin
* source/debug/tbrwtext.prg
! Bug fixed in Search() method.
Chen.
2009-11-08 06:25:00 UTC in Harbour
-
With Harbour rev12819, BCC32 default English locale I see no problem.
What is your Harbour version?
What is your C compiler version?
What is your OS version?
What Harbour locale (language driver/codepage) do you use?
What string are you trying to find?
Please supply a small self contained program that demonstrate the problem
Chen.
2009-11-04 10:15:09 UTC in Harbour
-
Danny,
According to the document in contrib/hbct/trig.c
all these trigonometric functions work on radians.
http://harbour-project.svn.sourceforge.net/viewvc/harbour-project/trunk/harbour/contrib/hbct/trig.c?revision=HEAD&view=markup
Chen.
2009-10-13 12:59:30 UTC in Harbour
-
Maurizio,
Issue was forwared to the dev list.
What is your Clipper version?
In Clipper - Do you use NTXSPA.OBJ to set sorting order?
if not, which OBJ do you use?
Chen.
2009-10-06 15:13:22 UTC in Harbour
-
The result depends on your C compiler math precision.
From your sample it seems to be limited to 15 digits
(which is the standard on most 32bit compilers).
You are trying to create a very large decimal which exceed this number (17 digits).
The math library must round the number. This is not a bug in Harbour.
Chen.
2009-10-05 22:02:57 UTC in Harbour
-
This is a reply made by Przemyslaw Czerpak on the dev list
in Thu, 1 Oct 2009 11:27:49 +0200:
----------------------------------------------------------------------
1. it's for old code with bugs which were fixed
2. if 1-st call to AdsOpenTable() success then uninitialized fRetry
is used as loop stop condition so the behavior is random and depends
on C stack context - potentialy...
2009-10-04 11:13:10 UTC in Harbour
-
Forwarded to the dev list.
2009-10-01 06:10:42 UTC in Harbour
-
---------------------------------------------
Here is a reply made by Viktor Szakats on the dev list
at Thu, 17 Sep 2009 15:10:18 +0200:
The easy solution is not to mix these two libraries, or
at least to use date functions from only one of them.
The difficult solution is to move each colliding functions
into separate source files. But even this may not solve
user problems, as it...
2009-09-21 07:32:25 UTC in Harbour
-
No details were givven, I don't see any special problem with rev12578
(2009-09-20 23:00 UTC+0200). Therefore I delete this entry.
Please supply more details if you wish to re-open thus bug report.
Chen.
2009-09-21 07:19:16 UTC in Harbour
