Problem with ADT integer on xharbour december build

Problem with ADT integer on xharbour december build

Postby Gianni » Thu Jan 10, 2008 3:11 pm

This little example create a simple ADT table with some integer fields.
It works with xharbour november build and show right values:
10000000
10000
100


with xharbour december build (and last CVS too!!!) don't works and show this:
****
****
**


Any suggestion?
Regards

Code: Select all  Expand view
#INCLUDE "ADS.CH"
#include "FiveWin.ch"

function Main()

   rddRegister( "ADS", 1 )
   rddsetdefault( "ADS" )
   SET SERVER LOCAL
   SET FILETYPE TO ADT

   DbCreate( "testadt.adt", { { "field1", "N", 8, 0 },;
                              { "field2", "N", 5, 0 },;
                              { "field3", "N", 3, 0 } } )

   USE testadt

   testadt->(dbappend())
   testadt->field1 := 10000000
   testadt->field2 := 10000
   testadt->field3 := 100
   testadt->(dbcommit())

   testadt->(dbgotop())
   testadt->(msginfo(str(field1) + CRLF + str(field2) + CRLF + str(field3)))

   USE

return nil

Gianni
 
Posts: 30
Joined: Fri Oct 07, 2005 6:58 am

Postby fgondi » Thu Jan 10, 2008 3:38 pm

Gianni,

This looks Post:
http://fivetechsoft.com/forums/viewtopic.php?t=9079&highlight=

The problem is the function str()
Used str( field1, 11) instead of str( field1 )
Un saludo
Fernando González Diez
ALSIS Sistemas Informáticos
User avatar
fgondi
 
Posts: 694
Joined: Fri Oct 07, 2005 6:58 am
Location: Palencia, España

Postby Gianni » Thu Jan 10, 2008 4:05 pm

Thank for answer
I don't think is a "str()" problem because
padl(field1,8,"0") returns "0000****"
and
padr(field1,8,"0") returns "****0000"
and this happen with xharbour december build and ONLY with ADT tables
Gianni
 
Posts: 30
Joined: Fri Oct 07, 2005 6:58 am

Postby fgondi » Thu Jan 10, 2008 4:50 pm

Gianni,

Correct.
It is not the function str(). These are all functions of converting numbers to characters from xharbour december build
Un saludo
Fernando González Diez
ALSIS Sistemas Informáticos
User avatar
fgondi
 
Posts: 694
Joined: Fri Oct 07, 2005 6:58 am
Location: Palencia, España

Postby Gianni » Mon Mar 17, 2008 3:59 pm

Any news about this problem?
It's still in last xharbour (02/2008).

Regards
Gianni
 
Posts: 30
Joined: Fri Oct 07, 2005 6:58 am

Postby Antonio Linares » Mon Mar 17, 2008 7:04 pm

Gianni,

Have you reported this bug to the xHarbour newsgroup ?

If not, we kindly request you to do it. Thanks,
regards, saludos

Antonio Linares
www.fivetechsoft.com
User avatar
Antonio Linares
Site Admin
 
Posts: 42080
Joined: Thu Oct 06, 2005 5:47 pm
Location: Spain

Postby toninhofwi » Tue Mar 18, 2008 12:08 am

This "problem" is in both Harbour/XHarbour. Please, see my next posts that are adressed to harbour developer list:

---cut---
Hi ppl,

With ADS, if the double field have large values like 1234567890123,
harbour displays ******** instead a value.

If I use str(field,20) the value is displayed correct.

A sample is in: http://www.fwi.com.br/toninho/adsdouble.zip

Thanks and best regards,

Toninho.
---cut---


---cut---
Przemek says:

Not only double. In ADS* RDDs non of numeric binary field sizes is
translated to valid size for decimal representation, f.e. the same
is for short ("I"/"short",2,0) and integer ("I"/"integer",4,0) when
the decimal representation will be bigger then 2 or 4 digits.
In each numeric item we keep default size for str() formating and
ADS RDDs sets this size to binary field size instead of maximum size
for binary representation. AFAIR this problems exists from the beginning.
It's ***only formatting*** problem when you do not explicitly set the size
but if you want to fix it then you should set valid size in adsGetValue()
function. It will be few lines only. You can take maximum sizes for all
types from dbf1.c or other RDDs I was working on (f.e. s_uiNumLength
translation table in delim1.c can be used for all integer sizes in
range 1,8)

Best regards,
Przemek
---cut---
toninhofwi
 
Posts: 172
Joined: Tue Oct 18, 2005 10:01 am


Return to FiveWin for Harbour/xHarbour

Who is online

Users browsing this forum: Google [Bot] and 73 guests