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
