Sorry I don't understand. I was talking exactly about alternate RTL library.
--------------------------------------------------
From: "Eduardo Fernandes" <modals...@yahoo.com.br>
Sent: Saturday, November 07, 2009 8:33 AM
To: "Xharbour-Developers List" <xharbour-developers@lists.sourceforge.net>;
"Ron Pinkas" <ron.pin...@xharbour.com>
Subject: Re: [xHarbour-developers] Proposal for HB_IS_NUMERIC.
> Maybe this is one way, but I would like to find a solution on RTL.
>
>
> Eduardo
>
> --- Em sáb, 7/11/09, Ron Pinkas <ron.pin...@xharbour.com> escreveu:
>
>> De: Ron Pinkas <ron.pin...@xharbour.com>
>> Assunto: Re: [xHarbour-developers] Proposal for HB_IS_NUMERIC.
>> Para: "Eduardo Fernandes" <modals...@yahoo.com.br>, "Xharbour-Developers
>> List" <xharbour-developers@lists.sourceforge.net>
>> Data: Sábado, 7 de Novembro de 2009, 13:30
>> I do not object to fixing
>> HB_C52_STRICT functionality, as long as the
>> extended functionality is NOT affected and remains the
>> default.
>>
>> Another choice is an optional new library which could be
>> built from existing
>> RTL sources, compiled with HB_C52_STRICT into a new
>> alternate RTLCL52.lib
>> and such lib could be linked instead of RTL.lib (by those
>> interested),
>> withOUT removing all extended features. IOW only Clipper
>> RTL functions would
>> be reduced to strict compatability.
>>
>> Ron
>>
>> --------------------------------------------------
>> From: "Eduardo Fernandes" <modals...@yahoo.com.br>
>> Sent: Saturday, November 07, 2009 7:17 AM
>> To: "Xharbour-Developers List"
>> <xharbour-developers@lists.sourceforge.net>;
>>
>> "Ron Pinkas" <ron.pin...@xharbour.com>
>> Subject: Re: [xHarbour-developers] Proposal for
>> HB_IS_NUMERIC.
>>
>> >
>> > I don't be able to compile xharbour using
>> HB_C52_STRICT. I got an error on
>> > achoice.prg and hbclass.ch by HB_SHORTNAMES is
>> disable. After enable
>> > HB_SHORTNAMES with HB_C52_STRICT enabled, then other
>> error occurs. It
>> > seems HB_C52_STRICT is broken.
>> >
>> > Eduardo
>> >
>> > --- Em sáb, 7/11/09, Ron Pinkas <ron.pin...@xharbour.com>
>> escreveu:
>> >
>> >> De: Ron Pinkas <ron.pin...@xharbour.com>
>> >> Assunto: Re: [xHarbour-developers] Proposal for
>> HB_IS_NUMERIC.
>> >> Para: "Eduardo Fernandes" <modals...@yahoo.com.br>,
>> "Xharbour-Developers
>> >> List" <xharbour-developers@lists.sourceforge.net>
>> >> Data: Sábado, 7 de Novembro de 2009, 11:29
>> >> This feature is already disabled if
>> >> you compile xHarbour with HB_C52_STRICT. Your
>> proposal can
>> >> NOT be implemented withOUT breaking existing code,
>> because
>> >> these String Functions must accept CHAR type to
>> support
>> >> existing code. The feature is documented in
>> xdiff.txt.
>> >>
>> >>
>> --------------------------------------------------
>> >> From: "Eduardo Fernandes" <modals...@yahoo.com.br>
>> >> Sent: Saturday, November 07, 2009 1:56 AM
>> >> To: "Xharbour-Developers List"
>> >> <xharbour-developers@lists.sourceforge.net>;
>> >> "Ron Pinkas" <ron.pin...@xharbour.com>
>> >> Subject: Re: [xHarbour-developers] Proposal for
>> >> HB_IS_NUMERIC.
>> >>
>> >> > Ron,
>> >> >
>> >> > I don't want remove this feature or break
>> existing
>> >> code. I would like this feature doesn't change the
>> expected
>> >> return values on any string functions.
>> >> >
>> >> > The question is: There is a way to separate
>> this
>> >> feature without remove it or break existing code,
>> and at
>> >> same time, maintain Clipper compatibility ?
>> >> >
>> >> > Maybe a #define HB_EXT_NUMERIC on hbapi.h.
>> >> >
>> >> > #ifdef HB_EXT_NUMERIC
>> >> > #define HB_IS_NUMERIC( p ) (
>> >> HB_IS_NUMBER( p ) || HB_IS_DATE(p) || (
>> HB_IS_STRING(p)
>> >> && (p)->item.asString.length == 1 ) )
>> >> > #else
>> >> > #define HB_IS_NUMERIC( p ) (
>> >> HB_IS_NUMBER( p ) || HB_IS_DATE(p) )
>> >> > #endif
>> >> >
>> >> >
>> >> > 1) Where this feature is documented ?
>> >> > 2) If I adopt this, what the impact into
>> xharbour core
>> >> ?
>> >> >
>> >> > regards,
>> >> > Eduardo
>> >> >
>> >> > --- Em sex, 6/11/09, Ron Pinkas <ron.pin...@xharbour.com>
>> >> escreveu:
>> >> >
>> >> >> De: Ron Pinkas <ron.pin...@xharbour.com>
>> >> >> Assunto: Re: [xHarbour-developers]
>> Proposal for
>> >> HB_IS_NUMERIC.
>> >> >> Para: "Eduardo Fernandes" <modals...@yahoo.com.br>,
>> >> "Xharbour-Developers List" <xharbour-developers@lists.sourceforge.net>
>> >> >> Data: Sexta-feira, 6 de Novembro de 2009,
>> 9:25
>> >> >> Eduardo,
>> >> >>
>> >> >> What makes no sense to a programmer can
>> be IGNORED
>> >> by THAT
>> >> >> programmer. Using a char value as numeric
>> makes
>> >> LOTs of
>> >> >> sense to many, especially those that
>> programs with
>> >> other
>> >> >> languages. Either way this is a
>> documented feature
>> >> which has
>> >> >> been available for many years. Therefore
>> we can't
>> >> simply
>> >> >> remove it and break existing code.
>> >> >>
>> >> >> Ron
>> >> >>
>> >> >> F.E. simple encoding
>> >> >>
>> >> >> sString := "Hello"
>> >> >> sCoded := ""
>> >> >>
>> >> >> FOR EACH cChar IN sString
>> >> >> sCoded += Str( cChar, 3
>> )
>> >> >> NEXT
>> >> >>
>> >> >> Ron
>> >> >>
>> >> >>
>> >>
>> --------------------------------------------------
>> >> >> From: "Eduardo Fernandes" <modals...@yahoo.com.br>
>> >> >> Sent: Thursday, November 05, 2009 5:56
>> PM
>> >> >> To: "Xharbour-Developers List"
>> >> >> <xharbour-developers@lists.sourceforge.net>;
>> >> >> "Ron Pinkas" <ron.pin...@xharbour.com>
>> >> >> Subject: Re: [xHarbour-developers]
>> Proposal for
>> >> >> HB_IS_NUMERIC.
>> >> >>
>> >> >> > Ron,
>> >> >> >
>> >> >> > I'm curious about what intention on
>> >> application with
>> >> >> these results:
>> >> >> >
>> >> >> > str('a',10,2) -> '
>> >> 97.00'
>> >> >> > strzero('b',10) -> '0000000098'
>> >> >> > padl("9","*",10) -> 42 spaces +
>> "9"
>> >> >> > padr("9","*",10) -> "9" + 42
>> spaces
>> >> >> > padc("9","*",10) -> 20 spaces +
>> "9" + 21
>> >> spaces
>> >> >> >
>> >> >> > IMO, this can cause damage on the
>> expected
>> >> results,
>> >> >> mainly from Clipper legacy applications.
>> >> >> >
>> >> >> > I still think more prudent to
>> separate this
>> >> *feature*
>> >> >> in HB_IS_NUMERIC_EXT and use it only on
>> specific
>> >> issues.
>> >> >> >
>> >> >> > Please, consider it.
>> >> >> >
>> >> >> > Eduardo
>> >> >> >
>> >> >> > --- Em qui, 5/11/09, Ron Pinkas
>> <ron.pin...@xharbour.com>
>> >> >> escreveu:
>> >> >> >
>> >> >> >> De: Ron Pinkas <ron.pin...@xharbour.com>
>> >> >> >> Assunto: Re:
>> [xHarbour-developers]
>> >> Proposal for
>> >> >> HB_IS_NUMERIC.
>> >> >> >> Para: "Eduardo Fernandes" <modals...@yahoo.com.br>,
>> >> >> "Xharbour-Developers List"
>> >> >> <xharbour-developers@lists.sourceforge.net>
>> >> >> >> Data: Quinta-feira, 5 de
>> Novembro de
>> >> 2009, 17:48
>> >> >> >> Eduardo,
>> >> >> >>
>> >> >> >> > So, we could review all
>> string
>> >> functions like
>> >> >> str(),
>> >> >> >> strzero(), pad(), etc, that
>> call
>> >> HB_IS_NUMERIC(),
>> >> >> >> HB_IT_NUMERIC or ISNUM() to
>> maintain, at
>> >> least,
>> >> >> expected
>> >> >> >> results or run time error, if
>> any
>> >> argument is
>> >> >> inverted or
>> >> >> >> with any data type changed.
>> >> >> >> >
>> >> >> >> > f.e.:
>> >> >> >> >
>> >> >> >> > ? str("a",10,2)
>> >> >> >> > ? strzero("b",10)
>> >> >> >> > ? padl("9","*",10)
>> >> >> >> > ? padr("9","*",10)
>> >> >> >> > ? padc("9","*",10)
>> >> >> >>
>> >> >> >> Please note that it is
>> absolutely VALID
>> >> CODE to
>> >> >> pass a
>> >> >> >> single char as a NUMERIC value.
>> I have
>> >> lot's of
>> >> >> such code
>> >> >> >> intentionally. It would
>> therefore be
>> >> wrong to
>> >> >> break a
>> >> >> >> documented feature which has
>> been working
>> >> for
>> >> >> years.
>> >> >> >>
>> >> >> >> Ron
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >>
>> >>
>> ____________________________________________________________________________________
>> >> >> > Veja quais são os assuntos do
>> momento no
>> >> Yahoo!
>> >> >> +Buscados
>> >> >> > http://br.maisbuscados.yahoo.com
>> >> >> >
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> >
>> >>
>> ____________________________________________________________________________________
>> >> > Veja quais são os assuntos do momento no
>> Yahoo!
>> >> +Buscados
>> >> > http://br.maisbuscados.yahoo.com
>> >> >
>> >>
>> >
>> >
>> >
>> >
>> ____________________________________________________________________________________
>> > Veja quais são os assuntos do momento no Yahoo!
>> +Buscados
>> > http://br.maisbuscados.yahoo.com
>> >
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal
>> Reports 2008 30-Day
>> trial. Simplify your report design, integration and
>> deployment - and focus on
>> what you do best, core application coding. Discover what's
>> new with
>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> xHarbour-developers mailing list
>> xHarbour-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/xharbour-developers
>>
>
>
>
> ____________________________________________________________________________________
> Veja quais são os assuntos do momento no Yahoo! +Buscados
> http://br.maisbuscados.yahoo.com
>
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
xHarbour-developers mailing list
xHarbour-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xharbour-developers
