Yes, but this require that those interested in such, will contribute the
Clipper strict compatibility version as an optional lib. This seems very
simple for me, but it must be contributed by those that are interested. If I
wanted Clipper, I'd be using Clipper, not xHarbour.
Ron
--------------------------------------------------
From: "Patrick Mast, xHarbour." <patrick.m...@xharbour.com>
Sent: Tuesday, November 10, 2009 6:21 AM
To: "Eduardo Fernandes" <modals...@yahoo.com.br>
Cc: "Miguel Angel Marchuet" <miguelan...@marchuet.net>; "Ron Pinkas"
<ron.pin...@xharbour.com>; "Xharbour-Developers List"
<xharbour-developers@lists.sourceforge.net>
Subject: Re: [xHarbour-developers] Proposal for HB_IS_NUMERIC.
> Hey Guys,
>
> Again, is NamesSpaces not the solution here?
> If I look at C:\xHarbour\source\rtl\namespaces.prg I even see we
> already HAVE a CL52 namespace! ;-)
>
> So, if I want a function to be Strict Clipper 5.2, I use CL52.PadL(...)
>
> Is this correct Ron?
>
> Patrick
>
>
>
> On Tue, Nov 10, 2009 at 2:56 PM, Eduardo Fernandes
> <modals...@yahoo.com.br> wrote:
>> Ron,
>>
>> Sorry for my insistency on this issue.
>>
>> >From 2 weeks ago I had a very bad experience on my fiscal app for that
>> >reason. Inadvertently I toggle second and third parameter on pad()
>> >function and the result was disastrous. If the RT error were generated,
>> >it could be avoided.
>>
>> I know this feature should be important in any cases, but I would like
>> that were optional.
>>
>> Maybe someone can have an idea.
>>
>> Eduardo
>>
>>
>>
>>
>> --- Em ter, 10/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>, "Miguel Angel
>>> Marchuet" <miguelan...@marchuet.net>
>>> Cc: "Xharbour-Developers List"
>>> <xharbour-developers@lists.sourceforge.net>
>>> Data: Terça-feira, 10 de Novembro de 2009, 9:13
>>> Eduardo,
>>>
>>> Your are posting wrong information about the CHAR type.
>>> CHAR (as numeric)
>>> type is ***ONLY*** acceptable in contexts where ONLY
>>> NUMERIC would be
>>> acceptable, IOW only when an ERROR would result!!!
>>> Specifically,
>>> ordSetFocus() and aScan() would never treat CHAR as NUMERIC
>>> because they do
>>> NOT REQUIRE a NUMERIC!!!
>>>
>>> Your proposal can't be accepted for the reasons I stated at
>>> least 3 times
>>> now. xHarbour will never remove that feature.
>>>
>>> Ron
>>>
>>> --------------------------------------------------
>>> From: "Eduardo Fernandes" <modals...@yahoo.com.br>
>>> Sent: Tuesday, November 10, 2009 2:41 AM
>>> To: "Ron Pinkas" <ron.pin...@xharbour.com>;
>>> "Miguel Angel Marchuet"
>>> <miguelan...@marchuet.net>
>>> Cc: "Xharbour-Developers List"
>>> <xharbour-developers@lists.sourceforge.net>
>>> Subject: Re: [xHarbour-developers] Proposal for
>>> HB_IS_NUMERIC.
>>>
>>> > Miguel,
>>> >
>>> > My proposal is justly enable RT error.
>>> >
>>> > 1) What return value you expect from substr('abcdef',
>>> '3' ) ?
>>> > 'abcdef' string, 'cdef' string , null
>>> string or RT error ?
>>> >
>>> > 2) where, on core xharbour code, is used a char as
>>> numeric parameter ?
>>> > like str('a',3) ?
>>> >
>>> > f.e. Inspecting cstr.prg, line 311, on valtoprgexp()
>>> function I found:
>>> >
>>> > 311 FOR EACH cChar IN xVal
>>> > 312 cRet += " + Chr(" +
>>> Str( Asc( cChar ), 3 ) + ")"
>>> > 313 NEXT
>>> >
>>> > It seems the correct way to do it.
>>> >
>>> > 3) From harbour "xhb-diff.txt" file:
>>> > -----
>>> > ### USING ONE CHARACTER LENGTH STRING AS
>>> NUMERIC VALUE ###
>>> > ================================================================
>>> > xHarbour uses one byte strings as
>>> numeric values corresponding to ASCII
>>> > value of the byte in a string, f.e.:
>>> > ? "A" * 10 //
>>> 650
>>> > By default Harbour core code does not
>>> give such functionality but
>>> > it has strong enough OOP API to allow
>>> adding such extension without
>>> > touching core code even by user at
>>> .prg level. It was implemented
>>> > in Harbour in XHB.LIB.
>>> > This code can be compiled and
>>> executed by both compilers:
>>> >
>>> > #ifndef
>>> __XHARBOUR__
>>> > #include
>>> "xhb.ch"
>>> > #endif
>>> > proc main()
>>> > local c :=
>>> "A"
>>> > ? c * 10, c -
>>> 10, c + 10, c * " ", chr( 2 ) ^ "!"
>>> > return
>>> >
>>> > and gives the same results.
>>> > Anyhow the emulation is not full
>>> here. It works only for .prg code.
>>> > In xHarbour standard C API
>>> functions/macros were modified to use
>>> > one byte string items as numbers.
>>> It's potential source of very serious
>>> > problems, f.e. ordSetFocus("1")
>>> should chose index called "1" or maybe
>>> > index 49 or what should return ascan(
>>> {49,"1"}, "1" ) (1 or 2)? so
>>> > Harbour developers decided to not add
>>> anything like that to core code
>>> > so in Harbour functions written in C
>>> refuse to accept one byte string
>>> > as number and code like
>>> > ? str( "0" )
>>> > generates runtime error instead of
>>> printing ' 48'.
>>> >
>>> > -----
>>> >
>>> > So, my proposal is isolate this feature like a number
>>> extension or other
>>> > solution to give me a RT error when, inadvertently a
>>> char is passed as
>>> > numeric parameter on string functions.
>>> >
>>> > IMO, this feature is dangerous.
>>> >
>>> > regards,
>>> > Eduardo
>>> >
>>> >
>>> >
>>> > --- Em seg, 9/11/09, Miguel Angel Marchuet <miguelan...@marchuet.net>
>>>
>>> > escreveu:
>>> >
>>> >> De: Miguel Angel Marchuet <miguelan...@marchuet.net>
>>> >> Assunto: Re: [xHarbour-developers] Proposal for
>>> HB_IS_NUMERIC.
>>> >> Para: "Ron Pinkas" <ron.pin...@xharbour.com>
>>> >> Cc: "Eduardo Fernandes" <modals...@yahoo.com.br>,
>>> "Xharbour-Developers
>>> >> List" <xharbour-developers@lists.sourceforge.net>
>>> >> Data: Segunda-feira, 9 de Novembro de 2009, 8:05
>>> >> I have read the conversation about
>>> >> numerical consideration.
>>> >>
>>> >> I propose an alternative solution RT error.
>>> Eliminating
>>> >> certain RT errors with pragmas
>>> >> for example:
>>> >>
>>> >> # pragma NoTestError = BASE | 1340
>>> >>
>>> >> not emerge for the 1340 runtime error division by
>>> 0 and be
>>> >> the default value 0
>>> >> course may only be prepared as disabled those
>>> functions.
>>> >> PADL, PADR.
>>> >>
>>> >> or when the key error exceeds 240 characters and
>>> thus
>>> >> operate as C/52 instead of C/53.
>>> >>
>>> >> # pragma NoTestError = DBFCDX | 1054
>>> >> [SPANISH]
>>> >> He leido atentamente la cnversación acerca de la
>>> >> consideración de numéricos.
>>> >>
>>> >> Propongo una solución alternativa, Eliminar
>>> ciertos RT
>>> >> error usando pragmas
>>> >> por ejemplo
>>> >>
>>> >> #pragma
>>> NoTestError=BASE|1340
>>> >>
>>> >> para que no emerja el runtime error 1340 division
>>> por 0 y
>>> >> resulte el valor por defecto 0
>>> >> evidentemente solo podran desactivarse aquellas
>>> funciones
>>> >> preparadas como. PADL, PADR.
>>> >>
>>> >> o bien el error cuando la key excede los 240
>>> caractereS y
>>> >> asi actue como en CL52 en lugar de CL53.
>>> >>
>>> >> #pragma
>>> NoTestError=DBFCDX|1054
>>> >>
>>> >>
>>> >> Best regards,
>>> >> Miguel Angel Marchuet
>>> >>
>>> >> Ron Pinkas escribió:
>>> >> > 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
>>> >> >
>>> >> >
>>> >> >
>>> >>
>>> ------------------------------------------------------------------------------
>>> >> > 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
>>> >> >
>>> >> > __________ Información de ESET NOD32
>>> Antivirus,
>>> >> versión de la base de firmas de virus 4578
>>> (20091106)
>>> >> __________
>>> >>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>
>
------------------------------------------------------------------------------
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
